A menudo se dice que el cambio es una constante del mundo

moderno. Ya sea que el cambio sea resultado de planificación

estratégica, forme parte de un programa transformacional
o se produzca en respuesta a un imperativo operacional, el
mecanismo para gestionar su entrega es y sigue siendo la
gestión de proyectos.

La versión actual del método PRINCE2TM ha sido diseñada con

miras a hacer más hincapié en los principios que sustentan
el éxito en la gestión de proyectos y para proporcionar
orientación clara sobre la manera de aplicar estos principios
al contexto organizativo dentro del cual operan los
proyectos. Este manual es, por consiguiente, una herramienta

Éxito en la Gestión de Proyectos con PRINCE2TM

fundamental para cualquier persona interesada en lograr
mayor éxito en la gestión de proyectos.

El desafío al cual se enfrentan todas las organizaciones,

grandes o pequeñas y ya sea dentro del sector público o Éxito en la Gestión de Proyectos con PRINCE2TM
privado, es la entrega de cambio a través de una gestión de
proyectos consecuente y sólida. Es aquí donde el método
PRINCE2 de gestión de proyectos realmente añade valor y se
confirma como la norma universalmente reconocida para lograr
éxito en la entrega de proyectos.

ISBN 9780113311651

www.tso.co.uk 9 780113 311651

Éxito en la Gestión de Proyectos con PRINCE2™

Londres: TSO
Publicado por TSO (The Stationery Office) y disponible:
En línea
www.tsoshop.co.uk

Por correo postal, teléfono, fax y correo electrónico

TSO
Apdo. de correos PO Box 29, Norwich, NR3 1GN, Reino Unido
Pedidos telefónicos/Información general: +44 (0) 870 600 5522
Pedidos por fax: +44 (0) 870 600 5533
Correo electrónico: customer.services@tso.co.uk

Agentes TSO@Blackwell y otros agentes

Los clientes también pueden encargar publicaciones a:

Diaz de Santos SA
Juan Bravo, 3-A, 28006 Madrid, España
+34 91 576 7382 Fax: +34 91 576 7316

Libreria Arroyave
Av. Cuauhtemoc 179, Col. Roma 06700, México, D.F., México
+52 5574 5069 Fax: +52 5564 5083

© Derechos de autor reservados por la Corona británica 2009

Publicado en nombre de la Oficina de Comercio Gubernamental del Reino Unido (OGC).

Esta publicación representa un producto de valor añadido, cuya reutilización requiere una
Licencia por parte de la OGC.
Cualquier solicitud para la reutilización, reproducción o republicación de material contenido
en esta publicación deberá enviarse a la OGC, The OGC Service Desk, Rosebery Court, St An-
drews Business Park, Norwich, Norfolk, NR7 0HS, Reino Unido. Teléfono +44 (0)845 000 4999,
Correo electrónico: servicedesk@ogc.gsi.gov.uk, o completando el formulario en línea en la
página web de OGC, en la sección de “Licensing”.
Derechos de autor en cuanto al diseño y criterios de imprenta son conferidos a The Stationery
Office Limited. Las solicitudes para la reproducción deberán presentarse por escrito a The
Stationery Office Limited, St Crispins, Duke Street, Norwich NR3 1PD, Reino Unido.

El logo Swirl ™ es una Marca Comercial de la OGC

El logo OGC® es una Marca Registrada de la OGC en el Reino Unido
PRINCE® es una Marca Registrada de la OGC en el Reino Unido y en otros países
PRINCE2™ es una Marca Comercial de la OGC en el Reino Unido y en otros países
ITIL® es una Marca Registrada de la OGC en el Reino Unido y en otros países
M_o_R® es una Marca Registrada de la OGC en el Reino Unido y en otros países
MSP™ es una Marca Comercial de la OGC
P3O® es una Marca Registrada de la OGC
P3M3™ es una Marca Comercial de la OGC

1996 Primera edición.

1998 Segunda edición.
2002 Tercera edición.
2005 Cuarta edición.
2007 Traducción al castellano de la cuarta edición inglés y publicación.
2009 Quinta edición.
2009 Traducción al castellano de la quinta edición inglés y publicación .

Todos los derechos de autor están reservados por la Corona británica en los respetivos años.

Primera publicación 2009

ISBN 978 0 11 3311651 1

Impreso en el Reino Unido por The Stationery Office.

Tabla de contenidos
Tabla de contenidos iii
Indice de figuras vi
Indice de tablas viii
Prefacio x
Agradecimientos xi
Convenciones utilizadas en este manual xiii
Notas sobre la traducción al castellano xiv
1 Introducción 3
1.1 El propósito de este manual 3
1.2 La importancia de los proyectos 3
1.3 ¿Qué hace que los proyectos sean
diferentes? 3
1.4 ¿Por qué tener un método de
gestión de proyectos? 4
1.5 Introducción a PRINCE2 4
1.6 Orientación complementaria de OGC 6
1.7 Beneficios de PRINCE2 8
2 Principios 11
2.1 Justificación comercial continua 11
2.2 Aprender de la experiencia 12
2.3 Roles y responsabilidades definidos 12
2.4 Gestión por fases 13
2.5 Gestión por excepción 14
2.6 Enfoque en los productos 14
2.7 Adaptación para corresponder
al entorno del proyecto 15
3 Introducción a las temáticas
de PRINCE2 19
3.1 ¿Qué son las temáticas? 19
3.2 Aplicación de las temáticas 20
3.3 Formato de las temáticas 20
4 Business Case 23
4.1 Propósito 23
4.2 Definición del Business Case 23
4.3 El enfoque del Business Case
según PRINCE2 24
4.4 Responsabilidades 30
5 Organización 35
5.1 Propósito 35
5.2 Organización definida 35
5.3 El enfoque de la organización
según PRINCE2 37
5.4 Responsabilidades 49
6 Calidad 53
6.1 Propósito 53
6.2 Definición de calidad 53
6.3 El enfoque de PRINCE2
hacia la calidad 55
6.4 Responsabilidades 65
7 Planes 69
7.1 Propósito 69
7.2 Definición de los planes 69
7.3 El enfoque de PRINCE2
hacia los planes 72
7.4 Responsabilidades 83
8 Riesgo 87
8.1 Propósito 87
8.2 Definición de riesgo 87
8.3 El enfoque de PRINCE2
hacia el riesgo 88
8.4 Responsabilidades 98
9 Cambio 103
9.1 Propósito 103
9.2 Definición de cambio 103
iv | Tabla de contenidos
9.3 El enfoque de PRINCE2
hacia el cambio 104
9.4 Responsabilidades 111
10 Progreso 115
10.1 Propósito 115
10.2 Definición de progreso 115
10.3 El enfoque de PRINCE2
sobre el progreso 116
10.4 Responsabilidades 124
11 Introducción a los procesos 129
11.1 Los procesos de PRINCE2 129
11.2 El trayecto de PRINCE2 129
11.3 El modelo de procesos de PRINCE2 131
11.4 Estructura de los capítulos
de los procesos 132
12 Puesta en Marcha de un Proyecto 137
12.1 Propósito 137
12.2 Objetivo 137
12.3 Contexto 138
12.4 Actividades 138
13 Dirección de un Proyecto 151
13.1 Propósito 151
13.2 Objetivo 151
13.3 Contexto 151
13.4 Actividades 152
14 Inicio de un Proyecto 165
14.1 Propósito 165
14.2 Objetivo 165
14.3 Contexto 166
14.4 Actividades 166
15 Control de una Fase 185
15.1 Propósito 185
15.2 Objetivo 185
15.3 Contexto 186
15.4 Actividades 186
16 Gestión de la Entrega de Productos 205
16.1 Propósito 205
16.2 Objetivo 205
16.3 Contexto 205
16.4 Actividades 206
17 Gestión de los Límites de Fase 213
17.1 Propósito 213
17.2 Objetivo 214
17.3 Contexto 214
17.4 Actividades 214
18 Cierre de un Proyecto 227
18.1 Propósito 227
18.2 Objetivo 227
18.3 Contexto 228
18.4 Actividades 228
19 Adaptación de PRINCE2 al
entorno del proyecto 239
19.1 ¿Qué es la adaptación? 239
19.2 Enfoque general de la adaptación 239
19.3 Ejemplos de adaptación de PRINCE2 241
19.4 Proyectos en un entorno
de programa 242
19.5 Escala del proyecto 247
19.6 Entorno
cliente/proveedor comercial 249
19.7 Proyectos multiorganizativos 252
19.8 Tipo de proyecto 253
19.9 Diferencias sectoriales 255
19.10 Gestión del proyecto -
Cuerpos de Conocimientos 256
Apéndice A: Contenido básico de las
Descripciones de Productos 261
A.1 Archivo sobre las Lecciones 261
A.2 Archivo Diario 263
A.3 Business Case 264
A.4 Descripción de Producto 265
A.5 Descripción del Producto
del Proyecto 267

A.6 Documentación de
Inicio del Proyecto 268
A.7 Estrategia de Gestión
de la Calidad 270
A.8 Estrategia de Gestión
de la Comunicación 271
A.9 Estrategia de Gestión
de la Configuración 272
A.10 Estrategia de Gestión
del Riesgo 273
A.11 Expediente del Proyecto 275
A.12 Ficha de UN Elemento de
Configuración 276
A.13 Informe al Final de Fase 277
A.14 Informe al Final de Proyecto 278
A.15 Informe de Cuestiones 279
A.16 Informe de Desarrollo 280
A.17 Informe de Excepción 281
A.18 Informe del Punto de Control 282
A.19 Informe sobre el
Estado de los Productos 282
A.20 Informe sobre las Lecciones 283
A.21 Paquete de Trabajo 284
A.22 Plan 286
A.23 Plan de Revisión de Beneficios 288
A.24 Registro de Calidad 288
A.25 Registro de Cuestiones 289
A.26 Registro de riesgos 290
Apéndice B: Gobierno 295
Apéndice C: Roles y responsabilidades 299
C.1 Junta de Proyecto 299
C.2 Ejecutivo 300
C.3 Usuario Principal 301
C.4 Proveedor Principal 301
C.5 Project Manager 302
C.6 Team Manager 303
C.7 Garantía del Proyecto 303
C.8 Autoridad de Cambios 305
C.9 Apoyo al Proyecto 306
Tabla de contenidos | v
Apéndice D: Ejemplo de
planificación basada en el producto 309
D.1 Escenario 309
D.2 Ejemplo de una Descripción
del Producto del Proyecto 311
D.3 Ejemplos de una
estructura jerárquica de productos 311
D.4 Ejemplo de una
Descripción de Producto 312
D.5 Diagrama de flujo de los productos 313
Apéndice E: Verificaciones 317
E.1 Puesta en Marcha de un Proyecto 317
E.2 Dirección de un Proyecto 318
E.3 Inicio de un Proyecto 321
E.4 Control de una Fase 322
E.5 Gestión de la Entrega de Productos 322
E.6 Gestión de los Límites de Fase 323
E.7 Cierre de un Proyecto 324
Apéndice F: Diccionario de términos 327
F.1 Principios 327
F.2 Temáticas 327
F.2 Procesos y Actividades 327
F.4 Productos de Gestión PRINCE2 328
F.5 Roles 329
F.6 Términos de glosario 329
Información adicional 333
Glosario 337
Índice 355
Indice de figuras
Fig. 1.1 Gestión de proyectos 5
Fig. 1.2 La estructura de PRINCE2 6
Fig. 1.3 Orientación de OGC sobre
mejores prácticas 7
Fig. 4.1 Relación entre resultados,
resultados finales y beneficios 24
Fig. 4.2 La ruta de desarrollo del
Business Case 25
Fig. 5.1 Los tres intereses en un proyecto 36
Fig. 5.2 Los cuatro niveles dentro de la
estructura de gestión del proyecto 37
Fig. 5.3 Estructura del equipo de
gestión del proyecto 37
Fig. 5.4 Posible estructura organizativa
utilizando grupos de usuarios
y de proveedores 42
Fig. 5.5 Las diversas facetas del rol
de Project Manager 43
Fig. 6.1 La secuencia de auditoría
de calidad 56
Fig. 7.1 Niveles de planificación
de PRINCE2 70
Fig. 7.2 El enfoque de PRINCE2
hacia los planes 72
Fig. 7.3 Técnica de planificación
basada en el producto 73
Fig. 7.4 Diagrama simple de
red de actividades 79
Fig. 8.1 Perspectivas organizativas 88
Fig. 8.2 El procedimiento de
gestión del riesgo 90
Fig. 8.3 Ejemplo de una
estructura jerárquica de riesgos 91
Fig. 8.4 Causa, evento y efecto de riesgo 92
Fig. 8.5 Tabla de probabilidad-impacto 94
Fig. 8.6 Perfil de riesgo abreviado 95
Fig. 8.7 Respuestas a amenazas
y oportunidades 95
Fig. 9.1 Procedimiento de control
de cambios y cuestiones 108
Fig. 9.2 Análisis de las opciones 109
Fig. 10.1 Delegación de tolerancia y
presentación de informes sobre
el progreso real y previsto 117
Fig. 10.2 Trabajo especializado
definido en fases técnicas 120
Fig. 10.3 Trabajo especializado que cruza
márgenes de fases de gestión 120
Fig. 10.4 Trabajo especializado
alineado con las fases de gestión 120
Fig. 11.1 Los procesos de PRINCE2 129
Fig. 11.2 Modelo de procesos de PRINCE2 131
Fig. 11.3 Relación entre procesos,
actividades y acciones 132
Fig. 12.1 Visión general de la
Puesta en Marcha de un Proyecto 137
Fig. 12.2 Resumen de actividades para
nombrar el Ejecutivo y
el Project Manager 139
Fig. 12.3 Resumen de actividades para
registrar lecciones anteriores 140
Fig. 12.4 Resumen de actividades para
diseñar y nombrar el equipo de
gestión del proyecto 141
Fig. 12.5 Resumen de actividades para
preparar el Business Case preliminar 143
Fig. 12.6 Resumen de actividades para
seleccionar el enfoque del proyecto y
elaborar el Expediente del Proyecto 145
Fig. 12.7 Resumen de actividades para
planificar la fase de inicio 146
Fig. 13.1 Visión general de la
Dirección de un Proyecto 151
Fig. 13.2 Resumen de actividades para
autorizar el inicio 152
Fig. 13.3 Resumen de actividades para
autorizar el proyecto 154
Fig. 13.4 Resumen de actividades para
autorizar un Plan de la Fase o
de Excepción 156
Fig. 13.5 Resumen de actividades para
proporcionar dirección ad hoc 158
Fig. 13.6 Resumen de actividades para
autorizar el cierre del proyecto 160
Fig. 14.1 Visión general del Inicio
de un Proyecto 165
Fig. 14.2 Resumen de actividades para
preparar la Estrategia de
Gestión del Riesgo 167

Fig. 14.3 Resumen de actividades para
preparar la Estrategia de Gestión
de la Configuración 169
Fig. 14.4 Resumen de actividades para
preparar la Estrategia de Gestión
de la Calidad 170
Fig. 14.5 Resumen de actividades para
preparar la Estrategia de Gestión
de la Comunicación 172
Fig. 14.6 Resumen de actividades para
establecer los controles del proyecto 174
Fig. 14.7 Resumen de actividades para
crear el Plan de Proyecto 176
Fig. 14.8 Resumen de actividades para
perfeccionar el Business Case 178
Fig. 14.9 Resumen de actividades para
preparar la Documentación
de Inicio del Proyecto 180
Fig. 15.1 Visión general del
Control de una Fase 185
Fig. 15.2 Resumen de actividades para
autorizar un Paquete de Trabajo 187
Fig. 15.3 Resumen de actividades para
revisar el estado del Paquete
de Trabajo 189
Fig. 15.4 Resumen de actividades para
recibir los Paquetes de Trabajo
completados 191
Fig. 15.5 Resumen de actividades para
revisar el estado de la fase 192
Fig. 15.6 Resumen de actividades para
informar sobre el desarrollo 195
Fig. 15.7 Resumen de actividades para
registrar y examinar cuestiones y
riesgos 197
Fig. 15.8 Resumen de actividades para
presentar excepciones relativas a
cuestiones y riesgos 199
Fig. 15.9 Resumen de actividades para
llevar a cabo rectificaciones 201
Fig. 16.1 Visión general del proceso de la
Gestión de la Entrega de Productos 205
Fig. 16.3 Resumen de actividades para
ejecutar un Paquete de Trabajo 208
Fig. 16.4 Resumen de actividades para
entregar un Paquete de Trabajo 210
Fig. 17.1 Visión general de la
Gestión de los Límites de Fase 213
Fig. 17.2 Resumen de actividades para
planificar la fase siguiente 215
Indice de figuras | vii
Fig. 17.3 Resumen de actividades para
actualizar el Plan de Proyecto 217
Fig. 17.4 Resumen de actividades para
actualizar el Business Case 218
Fig. 17.5 Resumen de actividades para
informar sobre el final de fase 220
Fig. 17.6 Resumen de actividades para
elaborar un Plan de Excepción 222
Fig. 18.1 Visión general del proceso del
Cierre de un Proyecto 227
Fig. 18.2 Resumen de actividades para
preparar el cierre planificado 229
Fig. 18.3 Resumen de actividades para
preparar el cierre prematuro 230
Fig. 18.4 Resumen de actividades para
entregar los productos 231
Fig. 18.5 Resumen de actividades para
evaluar el proyecto 233
Fig. 18.6 Resumen de actividades para
recomendar el cierre del proyecto 235
Fig. 19.1 Influencias en la exigencia
de adaptación 240
Fig. 19.2 Comparación entre proyectos
y programas 242
Fig. 19.3 Estructura organizativa con el
Ejecutivo como miembro de la
junta de programa 244
Fig. 19.4 Estructura organizativa con el
gerente del programa en calidad
de Ejecutivo del proyecto 244
Fig. 19.5 Un ejemplo de un ciclo de
vida de un estudio de viabilidad 254
Fig. A1 Evolución de los
productos de gestión baseline 262
Fig. D.1 Estructura jerárquica de
productos en forma de gráfico
jerárquico 309
Fig. D.2 Estructura jerárquica de productos
en forma de mapa conceptual 311
Fig. D.3 Ejemplo de un diagrama de flujo
de los productos para el proyecto
de la conferencia 313
Indice de tablas
Tabla 3.1 Las temáticas de PRINCE2 19
Tabla 4.1 Responsabilidades pertinentes
al Business Case 31
Tabla 5.1 Responsabilidades pertinentes a
la temática de la Organización 49
Tabla 6.1 La relación entre la Garantía
del Proyecto y la garantía de calidad 55
Tabla 6.2 Ejemplo de un Registro de Calidad 60
Tabla 6.3 Responsabilidades relacionadas
con la temática de Calidad 66
Tabla 7.1 Responsabilidades relacionadas
con la temática de Planes 83
Tabla 8.1 Ejemplo de la técnica de valor
monetario esperado 94
Tabla 8.2 Respuestas al riesgo 96
Tabla 8.3 Responsabilidades relacionadas
con la temática del Riesgo 99
Tabla 9.1 Tipos de cuestión 104
Tabla 9.2 Decisiones de la Junta de Proyecto 110
Tabla 9.3 Responsabilidades relacionadas
con la temática de Cambio 111
Tabla 10.1 Las seis áreas de tolerancia
por nivel 116
Tabla 10.2 Responsabilidades relacionadas
con la temática de Progreso 125
Tabla 11.1 Un ejemplo de tabla de
responsabilidades 132
Tabla 11.2 Leyenda para los diagramas de
procesos 133
Tabla 12.1 Responsabilidades para nombrar
el Ejecutivo y el Project Manager 140
Tabla 12.2 Responsabilidades para registrar
las lecciones anteriores 141
Tabla 12.3 Responsabilidades para diseñar y
nombrar el equipo de
gestión del proyecto 142
Tabla 12.4 Responsabilidades para preparar
el Business Case preliminar 144
Tabla 12.5 Responsabilidades para
seleccionar el enfoque del proyecto
y preparar el Expediente del Proyecto 146
Tabla 12.6 Responsabilidades para
planificar la fase de inicio 147
Tabla 13.1 Responsabilidades para
autorizar el inicio 153
Tabla 13.2 Responsabilidades para
el proyecto 155
Tabla 13.3 Responsabilidades para
autorizar un Plan de la Fase
o de Excepción 157
Tabla 13.4 Responsabilidades para
proporcionar dirección ad hoc 159
Tabla 13.5 Responsabilidades para
autorizar el cierre del proyecto 162
Tabla 14.1 Responsabilidades para
preparar la Estrategia de
Gestión del Riesgo 168
Tabla 14.2 Responsabilidades para
preparar la Estrategia de
Gestión de la Configuración 170
Tabla 14.3 Responsabilidades para
preparar la Estrategia de
Gestión de la Calidad 171
Tabla 14.4 Responsabilidades para
preparar la Estrategia de
Gestión de la Comunicación 173
Tabla 14.5 Responsabilidades para
establecer los controles del proyecto 175
Tabla 14.6 Responsabilidades para
crear el Plan de Proyecto 177
Tabla 14.7 Responsabilidades para
perfeccionar el Business Case 179
Tabla 14.8 Responsabilidades para
preparar la Documentación de
Inicio del Proyecto 181
Tabla 15.1 Responsabilidades para
autorizar un Paquete de Trabajo 188
Tabla 15.2 Responsabilidades para
revisar el estado del
Paquete de Trabajo 190
Tabla 15.3 Responsabilidades para
recibir el Paquete de
Trabajo completado 191
Tabla 15.4 Responsabilidades para
revisar el estado de la fase 194
Tabla 15.5 Responsabilidades para
informar sobre el desarrollo 196
Tabla 15.6 Responsabilidades de registrar
y examinar cuestiones y riesgos 198
Tabla 15.7 Responsabilidades para
presentar excepciones relativas
a cuestiones y riesgos 200
 Indice de tablas | ix

Tabla 15.8 Responsabilidades de

llevar a cabo rectificaciones 202
Tabla 16.1 Responsabilidades para
aceptar un Paquete de Trabajo 207
Tabla 16.2 Responsabilidades para
ejecutar un Paquete de Trabajo 209
Tabla 16.3 Responsabilidades para
entregar un Paquete de Trabajo 210
Tabla 17.1 Responsabilidades para
planificar la fase siguiente 216
Tabla 17.2 Responsabilidades para
actualizar el Plan de Proyecto 217
Tabla 17.3 Responsabilidades para
actualizar el Business Case 219
Tabla 17.4 Responsabilidades para
informar sobre el final de fase 221
Tabla 17.5 Responsabilidades para
elaborar un Plan de Excepción 223
Tabla 18.1 Responsabilidades para
preparar el cierre planificado 229
Tabla 18.2 Responsabilidades para
preparar el cierre prematuro 230
Tabla 18.3 Responsabilidades para
entregar los productos 232
Tabla 18.4 Responsabilidades
para el proyecto 234
Tabla 18.5 Responsabilidades para
recomendar el cierre del proyecto 235
Tabla 19.1 Adopción y adaptación 239
Tabla 19.2 Ejemplos de proyectos de
diferentes escalas 246
Tabla 19.3 Comparación entre PRINCE2
y un Cuerpo de Conocimientos 257
Tabla A1 Ejemplo de una lista de productos 287
Tabla B.1 Gobierno de los principios de
gestión del proyecto de la
Association for Project Management 295
Tabla D.1 Ejemplo de una Descripción
del Producto del Proyecto para
una conferencia anual 310
Prefacio
El uso de PRINCE2™ está ampliamente extendido Esta nueva edición cubre los principios de PRINCE2,
a escala mundial, en más de 150 países, y su reforzando las buenas prácticas que hacen que
utilización sigue aumentando. Está considerado un proyecto tenga éxito. Las temáticas describen
por muchos como el principal método de gestión aspectos de la gestión de proyectos que necesitan
de proyectos y más de 20.000 organizaciones ya se un tratamiento especial y los procesos describen
benefician de su enfoque fiable y novedoso. el progreso a lo largo del ciclo de vida de un
proyecto, desde su puesta en marcha hasta su
Esta orientación actualizada ayudará, a quienes
cierre. Se recomienda utilizar este manual junto
llevan a cabo proyectos de cualquier tamaño
con el manual asociado Directing Successful
y en cualquier entorno, a entregar de modo
Projects with PRINCE2 (TSO, 2009).
eficaz lo que el proyecto requiera, gestionando
correctamente los costes, los calendarios, la calidad, La cantidad de personas que se presentan a las
el alcance, los riesgos y los beneficios. Ha sido pruebas para certificarse en PRINCE2 aumenta
desarrollada tras amplias labores de consulta y se cada año en torno a un 20%, lo cual sigue siendo
apoya en experiencias reales de organizaciones algo que contribuye enormemente al éxito en
tanto del sector público como del sector privado. la entrega de proyectos. PRINCE2 es un método
fundamental para cualquier organización
En la actualidad, en los proyectos complejos a
que quiera garantizar unos resultados finales
menudo participan varias organizaciones que
operativos eficaces y eficientes.
trabajan juntas de forma asociada o mediante
acuerdos contractuales para lograr los objetivos.
PRINCE2 proporciona un lenguaje común que
las organizaciones pueden usar entre sí y con los
proveedores externos. También permite centrarse
en el Business Case, lo que proporciona un
mecanismo para definir lo que el proyecto trata de
lograr y las razones y la justificación comercial para
ello.
Esta última versión de Éxito en la Gestión de Nigel Smith
Proyectos con PRINCE2 constituye una evolución
respecto de los manuales anteriores. La Presidente
metodología básica se mantiene, pero al apoyarse Oficina de Comercio Gubernamental del Reino Unido
en comentarios de los usuarios, este nuevo manual
trata de ser más accesible y más fácil de adaptar a
las necesidades específicas de cada persona.
Agradecimientos
La Oficina de Comercio Gubernamental del Reino
Unido (OGC) ha seguido el desarrollo y la mejora
continua de la definición y presentación de
PRINCE2 en este manual. Se agradece al equipo de
autores su gran contribución, mediante relación
contractual, al diseño y desarrollo de este manual.
Autor principal
Andy Murray Outperform UK Ltd
Equipo de autores
Nigel Bennett Sun Microsystems Ltd
John Edmonds pearcemayfield
Bob Patterson Fujitsu Services
Sue Taylor Examinadora PRINCE2 de APMG
Graham Williams GSW Consultancy Ltd
Revisor y asesor principal
Colin Bentley Examinador Jefe de PRINCE2 Askew, Housing Corporation; Richard Aspden,
1998-2008
Otras contribuciones
Para garantizar que el manual de la OGC Éxito en la
Gestión de Proyectos con PRINCE2 (2009) continúa
reflejando fielmente las tendencias actuales y futuras
en el ámbito internacional de las mejores prácticas
de gestión de proyectos, y para preparar una
orientación con vigencia a largo plazo, la OGC ha
llevado a cabo amplias consultas con las principales
partes interesadas y expertos en cada fase del
proceso. OGC quisiera agradecer la contribución que
han realizado a esta nueva orientación las siguientes
personas y organizaciones:
Grupo de referencia de PRINCE2
Rob Brace, Ministerio de Trabajo y Pensiones;
Andrew Bragg, Director General, APM; Prof.
Christophe Bredillet, ESC Lille; Terry Cooke Davis,
Human Systems; Lynne Crawford, Universidad
de Sidney; John Cutting, MOD (DPA – DE&S);
Prof. Darren Dalcher, Centro Nacional de Gestión
de Proyectos, Universidad de Middlesex; Steve
Falkenkrog, PMI; Ruth Little, Centro de Proyectos
de DTI; Dusty Miller, Sun Microsystems Ltd; Bob
Patterson, Fujitsu; Philip Rushbrook, Oficina del
Consejo de Ministros; Beverley Webb, Comité
estándar de BSI Project Management; Jens Wandel,
Director, UNDP
PRINCE2:2009 gobierno del proyecto
Mike Acaster, OGC, Ejecutivo del Proyecto; Eddie
Borup, BPUG, Usuario Principal; Anne-Marie Byrne,
TSO, Project Manager; Janine Eves, TSO, Proveedor
Principal; Sandra Lomax, BPUG, Usuario Principal;
Richard Pharro, APMG, Proveedor Principal
Panel de control de cambios
Coos Groot, Best Practice User Group (PRINCE2
Italia); Peter Johnson, Peter Johnson PJ Ltd; Sheila
Roberts, Cupe Ltd; Martin Rother, Best Practice
User Group (PRINCE2 Alemania); David Watson,
ADt Partnership
Revisores
Robert Allen, PRS for Music; Adalcir da Silva
Angelo, Elumini IT & Business Consulting; Paul
Pathfinder Project Management; Gareth Atwood,
Foster Wheeler Energy; Marc Baetens, Pronohau
Ltd; Andrew Ball, Comisión Británica de Auditoría
Pública; Jim Barker, Curtis & Cartwright Consulting
Ltd; Keith Batchelor, Foster Wheeler Energy; Dick
Bennett, Asesor Jefe de APMG; Kate Blackall,
Examinadora de APMG PRINCE2; Johan Bleeker,
Standard Bank; Eddie Borup, Ibps solutions; Chris
Braithwaite, Wellstream; George Brooke, Oak
Lodge Consulting Ltd; Mark Canning, Agencia
de Desarrollo Regional del Noroeste; Tim Carroll,
Standard Chartered Bank; Jacqueline Chadwick,
VOSA; Sue Childs, Examinadora de APMG PRINCE2;
Alison Clack, Sean Alison Ltd; Jim Clinch, Clinch
Consulting; Brian Coombes, The Projects Group;
Arthur Coppens, Getronics Consulting Educational
Services; Bjarne Corvinius, Rovsing Management ;
Anthony Dailey, MWH; Terry Dailey, Deliverables
Management Consultants; Bill Duncan, Examinador
de APMG PRINCE2; Hassan El Meligy , IEEE; Darilyn
Evans, Adaptive Frameworks; Alan Ferguson, AFA;
Chris Ferguson, Novare Consulting Ltd; Ray Frew,
Aspen Management Training; Alvin Gardiner,
PR-02 (Scotland) Ltd; Emmanuel Gianquitto, APMG
(Internacional); Colin Graham, Aylesbury Vale DC;
John Greenwood, CSC; Angelika Hamilton, APMG
(Alemania); Gary R O Haran Doyle, Swiss Life ;
Simon Harris, Logical Model Ltd; Wietse Heidema,
Opmaat Consultancy & Training; Luis Herrera,
xii | Agradecimientos

Asesor; Terry Hewins, Registro de la Propiedad; Grupo piloto de Éxito en la Gestión de

Emma Jones, Examinadora Jefe de PRINCE2 para Proyectos con PRINCE2
APMG; Nigel Jones, AJS; Howard Joseph, Ministerio
The British Council; Capital Coast District Health
del Interior; Ravi Joshi, Action For Children; Hans
Board; Ministerio de Trabajo (Nueva Zelanda);
Kemper, APMG (Holanda); Eddie Kilkelly, ILX
Fishserve; Policía Metropolitana británica;
Group plc; Lawrie Kirk, Tanner James Management
Ministerio de Desarrollo Económico (Nueva
Consultants (Australia); Wieslaw Kosieradzki,
Zelanda); Ministerio de Educación (Nueva Zelanda);
P2Ware; Eddie Lamont, Policía de Lothian y
Ayuntamiento del distrito metropolitano de
Fronteras; Tony Levene, Quality Projects; Martin
Staffordshire; Standard Bank; Ayuntamiento
Lewis , Lucid IT; David Lillicrap, Distrito londinense
del condado de Suffolk; Sun Microsystems Ltd;
de Ealing; Steve Livingstone, BNFL; Tim Lulham,
Academia Vietnamita de Ciencias Sociales.
Network Rail; Maria Maltby, Ayuntamiento
del distrito de Charnwood; Dusty Miller, Sun Equipo de traducción
Microsystems Ltd; Trevor Mirams, Parity; Adrian
Newton, Quorum ICT; Bruce Nicholls , Bryan Cave; Emmanuel Gianquitto, APMG Internacional
Helen Nicoll, NHS (sistema británico de sanidad Coordinación general y revisión de la calidad
pública); Chris Price, Departamento de Autopistas; Federico Pérez Pierotti, Bibbo Services Ltd
G. Raghunandan, Satyam Computer Services Ltd; Revisión técnica y estilística
Geoff Rankins, Goal Professional Services Pty
Ltd; Lizz Robb, Yellowhouse.net pty Ltd; Graham RWS Group, Translation division
Robertson, Serco; Eileen Roden, PM Professional Traducción y revisión
Learning; Philip Rushbrook, Oficina del Consejo Vincenzo Imerti, QRP International
de Ministros; Ian Santry, Ministerio del Interior; Contribución a la revisión
Andrew Schuster, Ministerio de Sanidad; Noel
Tess Brennan, Digital Printing Services
Scott, Symantec; John Sherwood, Departamento de
Autoedición
Autopistas; Joy Shewring, APMG (Estados Unidos);
Jay M. Siegelaub, Impact Strategies LLC; Raed M.
Skaf, Oger Systems Ltd; Tim Sneller, Ayuntamiento
del distrito de Southend-on-Sea; Rod Sowden,
Aspire Europe Ltd; Phil Stephensen-Payne, Remarc
Group; Rob Sucher, Armstrong Webb; Mark Sutton,
SCOLL Methods Ltd; Ian Thomas, Liberty Network
Consultancy; Dot Tudor, TCC ; Bram de Vuyst,
Getronics Consulting Management Services; Jens
Wandel, Programa de Desarrollo de Naciones
Unidas; Geoff Ward, Examinador de APMG
PRINCE2; Sheryl Ward, Skandia; Peter Weaver,
Corte-grande; David Whelbourn , Xwave solutions
inc; Stephen Wierzbicki, Bristol Management
Centre; Jorn Wigh, APMG (Dinamarca); Gerald
Williams, Projectlabs; Philip Wilson, Oficina del
Consejo de Ministros
Convenciones utilizadas en este manual

A lo largo de este manual, los siguientes términos

comenzarán con mayúscula:
■■ Las temáticas de PRINCE2
■■ Los procesos de PRINCE2
■■ Los roles de PRINCE2
■■ Los productos de gestión definidos
Siempre se hará referencia a las actividades dentro
de los procesos de PRINCE2 utilizando las mismas
palabras o frases clave; no tienen ninguna otra
característica distintiva, ya que deben ser evidentes
por el contexto. Por ejemplo: “La Junta de
Proyecto proporcionará dirección ad hoc en estas
circunstancias”.
En general, se han evitado las abreviaturas y
acrónimos; sin embargo, en los casos en que se
usan, se indicará su ortografía completa la primera
vez que se utilicen.
Los puntos principales se ilustran de este modo:

Un proyecto de PRINCE2 tiene una justificación

comercial continua.

Los ejemplos de técnicas se ilustran de este modo:

Ejemplo de una técnica de ordenación por

prioridad - DDPN
Cada criterio de aceptación se clasifica como
algo que se Debe obtener, se Debería obtener,
se Podría obtener o No se obtendrá por ahora
(DDPN)
Debería ser posible lograr todos los criterios de
aceptación del tipo “Debe obtener” y “Debería
obtener” sin que se excluyan entre sí.
Notas sobre la traducción
La traducción del texto original en inglés ha pasado
por un minucioso proceso de traducción y revisión,
a cargo de traductores y revisores profesionales,
expertos en el sector de la gestión de proyectos.
El mismo equipo se ha encargado también de la
traducción de todos los exámenes de certificación
disponibles para garantizar la homogeneidad de la
traducción. El texto de esta publicación ha pasado
por cuatro niveles de revisión: inicial, técnica,
estilística y final. Se ha tratado, en lo posible, de
evitar giros y expresiones que puedan entenderse
de distinta manera en los distintos países
hispanoparlantes.
Es importante considerar algunas expresiones tales
como:
■■ Records – Este término se utiliza en la versión
en inglés con dos sentidos. En la traducción se
emplea Testimonio Documental cuando se hace
referencia a las evidencias que se conservan de
algunas actividades (como el resultado de una
revisión de calidad); mientras que se emplea la
palabra Ficha cuando se indica el soporte físico
que se utiliza para registrar algo (como la Ficha
de un Elemento de Configuración).
■■ Reporting – También este término en inglés
se utiliza con dos acepciones diferentes. Se
ha traducido como Rendir Cuentas, cuando la
presentación de informes implica, además, el
concepto de jerarquía y responsabilidades y
como Informar cuando, simplemente, se hace
referencia a la actividad de presentar informes.
■■ Issue – Se ha decidido traducir esta palabra
utilizando el término Cuestión. En PRINCE2
el concepto de issue es genérico y, por lo
tanto, no se ha considerado apropiado utilizar
traducciones que impliquen connotaciones
negativas como problema o incidente. Una
cuestión se registra y luego se analiza para
averiguar si entra en la categoría de solicitudes
de cambios, fuera de especificación o problemas
genéricos.
■■ Accountable / Responsible – En la temática
sobre organización, se hace referencia a
la necesidad de delegar tareas concretas
(responsibilities) a otros roles, pero sin perder
en ningún caso la responsabilidad final
(accountability). En otras palabras, se habla de
delegar la responsabilidad de llevar a cabo una
tarea y no la responsabilidad final sobre ella.
La decisión estilística que se ha tomado en este
manual ha sido la de traducir Accountability
y Responsability como Responsabilidad y
Delegación o empleando la perífrasis de
Responsabilidad Final y Responsabilidad
Delegada.
■■ Business Case, release y baseline son algunos
de los términos que los profesionales de
la gestión de proyectos consideran de uso
común en su versión original y por lo tanto
así se emplean en este manual. Sin embargo,
la flexibilidad de PRINCE2 permite cambiar
estos términos por otros en la adaptación del
método a las necesidades específicas que así lo
requieran. Véase el capítulo 19.
Los títulos de los textos que no se han traducido
todavía, se han dejado en su original en inglés.
Todos los términos específicos utilizados en este
manual se definen en el Glosario de Términos en la
sección final. Para más información sobre cómo se
ha traducido la terminología específica del inglés,
véase el Apéndice F.
Introducción 1
1 Introducción
1.1 El propósito de este manual
PRINCE2 (Projects in a Controlled Environment, o
proyectos en un entorno controlado) es un método
estructurado para gestión de proyectos que se basa
en las experiencias de miles de proyectos y en las
contribuciones de un sinfín de patrocinadores de
proyectos, Project Managers, equipos de proyectos,
académicos, formadores y consultores. Este manual
se ha diseñado:
■■ Para personal de gestión de proyectos a nivel de
comienzo de carrera que quiere aprender sobre
gestión de proyectos en términos generales y
sobre el método PRINCE2 en particular
■■ Para Project Managers y personal con
experiencia que quieren aprender sobre el
método PRINCE2
■■ Como fuente de consulta detallada para
aquellos certificados como PRINCE2 Practitioners
■■ Como fuente de información sobre PRINCE2
para los gerentes que están considerando si
deberían adoptar el método.
El manual cubre las preguntas frecuentemente
formuladas por la gente que participa en la gestión
de proyectos y en roles de apoyo. Estas preguntas
incluyen:
■■ ¿Qué se espera de mí?
■■ ¿Qué hace el Project Manager?
■■ ¿Qué hago si las cosas no salen como se había
planeado?
■■ ¿Qué decisiones se espera que debo tomar?
■■ ¿Qué información necesito o debo suministrar?
■■ ¿A quién debería pedir apoyo o instrucciones
de trabajo?
■■ ¿Cómo puedo adaptar el uso de PRINCE2 para
mi proyecto?
1.2 La importancia de los
proyectos
Un desafío principal para las organizaciones en
el mundo de hoy es poder mantener el equilibrio
entre dos imperativos paralelos que compiten
entre sí:
■■ Mantener las operaciones comerciales actuales
– rentabilidad, calidad de servicio, relaciones
con el cliente, lealtad a la marca, productividad,
confianza en el mercado, etc., lo que llamamos
negocio habitual o business as usual
■■ Transformar las operaciones comerciales a fin
de sobrevivir y competir en el futuro, – con la
mirada hacia adelante y decidiendo la manera
en que se pueden introducir cambios en el
negocio para que den el mejor resultado para la
organización.
A medida que acelera el ritmo del cambio
(tecnológico, comercial, social, regulador, etc.) y
el precio pagado por no adaptarse al cambio es
más evidente, la atención de la gestión se centra
inevitablemente en el logro de un equilibrio entre
el negocio habitual y el cambio comercial.
Los proyectos son el medio mediante el cual
se introducen cambios y, si bien muchas de las
competencias requeridas son las mismas, hay ciertas
diferencias de crucial importancia entre la gestión
del negocio habitual y la gestión del trabajo de un
proyecto.
1.3 ¿Qué hace que los proyectos
sean diferentes?
Un proyecto es una organización temporal que
se crea con el propósito de entregar uno o más
productos comerciales según un Business Case
convenido.
Hay una serie de características del trabajo de un
proyecto que lo distinguen del negocio habitual:
■■ Cambio - Los proyectos son el medio mediante
el cual se introducen cambios
4 | Introducción
■■ Temporal - Como indica la definición anterior,
los proyectos son de naturaleza temporal.
Una vez que el cambio deseado se ha
implementado, se reanuda el negocio habitual
(en su nueva forma) y se elimina la necesidad
del proyecto. Los proyectos deberían tener un
inicio y un fin definidos
■■ Interfuncional - Los proyectos dan participación
a un equipo de personas con competencias
diferentes que trabajan juntas (temporalmente)
para introducir un cambio que tendrá un
impacto en otros fuera del equipo. Los
proyectos a menudo van más allá de las
divisiones funcionales normales dentro de una
organización y a veces atañen a organizaciones
totalmente diferentes. Esto frecuentemente
causa tensión y presiones, tanto dentro de
las organizaciones como entre, por ejemplo,
clientes y proveedores. Cada uno tiene una
perspectiva y un motivo diferentes para
participar en el cambio
■■ Único - Cada proyecto es único. Una
organización podrá realizar muchos proyectos
similares y establecer un tipo de actividad
familiar y de probada eficacia para el proyecto,
pero cada uno de ellos será único de alguna
manera: un equipo diferente, un cliente
diferente, un lugar diferente. Todos estos
factores se combinan para hacer que cada
proyecto sea único
■■ Incertidumbre - Evidentemente, las
características ya enumeradas introducirán
amenazas y oportunidades más allá de aquellas
a las que típicamente nos enfrentamos en el
transcurso del negocio habitual. Los proyectos
presentan mayores peligros.
1.4 ¿Por qué tener un método de
gestión de proyectos?
La gestión de proyectos es la planificación,
delegación, seguimiento y control de todos
los aspectos del proyecto y la motivación
de aquellos que participan para lograr los
objetivos del proyecto dentro de las metas de
rendimiento previstas para duración, coste,
calidad, alcance, beneficios y riesgos.
Es el desarrollo de los productos a entregar del
proyecto (conocidos simplemente como productos
en PRINCE2) lo que entrega los resultados del
proyecto. Una casa nueva se completa al crear
dibujos, cimientos, suelos, paredes, ventanas, un
techo, cañerías, cableado y servicios afines. Nada de
esto es la gestión del proyecto – por lo tanto, ¿por
qué necesitamos gestión del proyecto? El propósito
de la gestión del proyecto es mantener el control
sobre el trabajo especializado que se requiere para
crear los productos del proyecto o, para continuar
con la analogía con la casa, para asegurar que el
contratista encargado del techo no llegue antes de
que se construyan las paredes.
Además, debido a que los proyectos son el medio
para introducir cambios comerciales y que el
trabajo del proyecto implica un mayor grado de
riesgo que otra actividad comercial, se deduce que
implementar un enfoque seguro, consecuente y de
probada eficacia a la gestión de un proyecto es una
inversión comercial valiosa.
1.5 Introducción a PRINCE2
PRINCE2 es un método de dominio público y ha
emergido en todo el mundo como uno de los
métodos más ampliamente aceptados para la
gestión de proyectos. Esto se debe en gran parte
al hecho de que PRINCE2 es verdaderamente
genérico: se puede aplicar a cualquier proyecto,
sin importar la escala del proyecto, su tipo,
organización, ubicación geográfica o cultura.
PRINCE2 logra esto al aislar los aspectos de
la gestión del trabajo del proyecto de las
contribuciones especializadas tales como diseño,
construcción, etc. Los aspectos especializados de
cualquier tipo de proyecto se integran con toda
facilidad con el método PRINCE2 y, al utilizarse
junto con PRINCE2, proporcionan un marco general
seguro para el trabajo del proyecto.
Debido a que PRINCE2 es genérico y se basa en
principios de probada eficacia, las organizaciones
que adoptan el método como patrón pueden
mejorar considerablemente la capacidad de su
organización y su madurez en múltiples áreas de
la actividad comercial – cambios en el negocio,
construcción, tecnología de la información,
fusiones y adquisiciones, investigación, desarrollo
de productos, etc.

1.5.1 ¿Qué hace un Project Manager?
Para mantener control sobre cualquier cosa,
debe existir un plan. Es el Project Manager quien
planifica la secuencia de actividades para construir
la casa, quien determina la cantidad de albañiles
que se requerirán, etc.
Quizás sea posible que usted mismo se haga cargo
de construir la casa, pero hacerse cargo, es decir ser
gerente, significa que usted delegará todo o parte
del trabajo a otros. La competencia para delegar
es importante en cualquier tipo de gestión pero
especialmente en la gestión de proyectos (debido a
la interfuncionalidad y los riesgos).
Una vez que el trabajo delegado se ha iniciado, el
objetivo es que ‘salga según el plan’, pero no se
puede confiar en que éste siempre sea el caso. El
Project Manager es responsable del seguimiento
de la medida en que el trabajo en curso se ajusta al
plan.
Por supuesto, si el trabajo no sale como estaba
planeado, el Project Manager tiene que hacer
algo para remediar esto, es decir, ejercer control.
Aun si el trabajo va bien, el Project Manager
podría ver una oportunidad para acelerarlo o para
reducir costes. Ya sea mediante rectificación o al
implementar medidas para mejorar el rendimiento,
el objetivo de PRINCE2 es poner la información
correcta a disposición en el momento correcto para
que la gente correcta tome decisiones correctas.
Plan
Planificar
Controlar
Control Delegar
Delegate
Monitorizar
Monitor
Figura 1.1 Gestión de proyectos
1.5.2 ¿Qué es lo que se quiere
controlar?
En cualquier proyecto hay seis variables en juego y,
por consiguiente, seis aspectos del rendimiento del
proyecto que se deben gestionar.
■■ Costes - El precio del proyecto debe ser
asequible y si bien podríamos empezar con un
presupuesto determinado en mente, habrá
Introducción | 5
muchos factores que pueden ocasionar gastos
excesivos y, quizás, algunas oportunidades para
reducir los costes
■■ Calendarios - Sumado a esto, y probablemente
la pregunta que inmediatamente después y
con mayor frecuencia se le formula a un Project
Manager es: ‘¿Cuándo estará terminado?’
■■ Calidad - Terminar a tiempo y dentro del
presupuesto no es un gran consuelo si no se
logra el resultado del proyecto. En términos de
PRINCE2, los productos del proyecto deben ser
aptos para el propósito
■■ Alcance - ¿Qué entregará el proyecto
exactamente? Sin saberlo, las diversas partes
de un proyecto muy a menudo pueden estar
hablando de cosas distintas al respecto. El
cliente podría suponer, por ejemplo, que un
cuarto de baño y/o una cocina amueblados
están incluidos en el precio de la casa, mientras
que el proveedor considera que éstos son
‘extras’. En proyectos de gran escala, la
definición del alcance es mucho más sutil y
compleja. Debe haber acuerdo con respecto
al alcance del proyecto y el Project Manager
necesita comprender exactamente qué es lo
que está, o no, dentro del alcance. El Project
Manager debería tener cuidado de no ir más
allá del alcance ya que esto comúnmente causa
demoras, déficit presupuestario y cambios
descontrolados (‘aumento del alcance’ o scope
creep)
■■ Riesgo - Todos los proyectos conllevan riesgos
pero ¿cuánto riesgo estamos dispuestos a
aceptar exactamente? ¿Deberíamos construir la
casa cerca del terreno de una mina en desuso,
que podría ser propenso a hundimiento? Si
decidimos construirla, ¿hay algo que podamos
hacer para tratar el riesgo? ¿Quizás contratar
un seguro o encargar inspecciones rigurosas?
■■ Beneficios - Tal vez la pregunta que más a
menudo se pasa por alto es ‘¿por qué estamos
haciendo esto?’ No es suficiente construir
la casa con éxito y a tiempo, dentro del
presupuesto y conforme a las especificaciones
de calidad si, después de todo, no la podemos
vender ni alquilar con ganancia ni vivir en
ella felizmente. El Project Manager debe
comprender claramente el propósito del
proyecto como una inversión y asegurarse
de que aquello que el proyecto entregue sea
consecuente con el logro del beneficio deseado.
6 | Introducción
PRINCE2 es un marco integrado de procesos y
temáticas que abordan la planificación, delegación,
seguimiento y control de estos seis aspectos del
rendimiento del proyecto.
1.5.3 La estructura de PRINCE2
El método PRINCE2 aborda la gestión de proyectos
con cuatro elementos integrados de principios,
temáticas, procesos y el entorno del proyecto
(Figura 1.2).
1 Los principios (Capítulo 2)
Éstos son las obligaciones y buenas prácticas
orientadoras que determinan si el proyecto se está
gestionando genuinamente utilizando PRINCE2.
Hay siete principios y, a menos que se apliquen
todos ellos, no se trata de un proyecto PRINCE2.
ENTORNO DE PROYECTO
Progreso
Cambio PROCESOS DE PRINCE2
Riesgo
TEMÁTICAS DE PRINCE2
PRINCIPIOS DE PRINCE2
Figura 1.2 La estructura de PRINCE2
2 Las temáticas (Capítulos 3 a 10)
Éstas describen aspectos de la gestión del proyecto
que se deben abordar continuamente y en paralelo
durante todo el proyecto. Las siete temáticas
explican el tratamiento específico requerido por
PRINCE2 para varias disciplinas de gestión de
proyectos y por qué son necesarias.
3 Los procesos (Capítulos 11 a 18)
Éstos describen una progresión paso a paso
del ciclo de vida del proyecto, desde la puesta
en marcha hasta el cierre del proyecto. Cada
proceso provee listas de control para las
actividades recomendadas, los productos y las
responsabilidades afines.
4 Adaptación de PRINCE2 al entorno del
proyecto (Capítulo 19)
Este capítulo aborda la necesidad de adaptar
PRINCE2 al contexto específico del proyecto.
PRINCE2 no es una solución única para dejar
contentos a todos; es un marco flexible que se
puede adaptar con facilidad a cualquier tipo o
tamaño de proyecto.
Hay una guía complementaria, Directing Successful
Projects with PRINCE2 que aborda el método
PRINCE2 desde el punto de vista del personal
directivo superior, específicamente los miembros de
la Junta de Proyecto.
Business
Case
Organización
Calidad
Planes
1.6 Orientación complementaria
de OGC
PRINCE2 es parte de una serie de pautas
desarrolladas por la Oficina de Comercio
Gubernamental del Reino Unido (OGC), que busca
ayudar a las organizaciones y a las personas a
gestionar sus proyectos, programas y servicios de
manera consecuente y con eficacia. La Figura 1.3
resume la estructura del conjunto.
En los casos en que sea apropiado, los métodos y la
orientación de OGC se incrementan con programas
de cualificación y todos los aspectos se apoyan con
capacitación acreditada y servicios de consultoría.
Los detalles de estas guías sobre mejores prácticas y
de otras guías pertinentes se podrán encontrar en
Más Información.
 Introducción | 7

1.6.1 Aquello que PRINCE2 no provee
PRINCE2 no busca (ni le es posible) cubrir cada uno
de los aspectos de la gestión de proyectos. Hay tres
amplias categorías de temas que expresamente se
consideran fuera del alcance de PRINCE2:
■■ Aspectos especializados – La solidez de PRINCE2
se basa en su amplio campo de aplicación
que es totalmente genérico. Por consiguiente,
se excluyen del método las actividades que
pertenecen a tipos específicos de industrias. Es
posible utilizar modelos de ingeniería, ciclos
de vida de proyectos o técnicas específicas
como gestión de cambios en la organización o
técnicas de adquisición en paralelo a PRINCE2.
Todos estos aspectos más específicos del trabajo
de un proyecto, se denominan en PRINCE2
como ‘especializados’. Esto también significa
que es necesario identificar e incluir en el
alcance y planes del proyecto los productos
especializados necesarios.
■■ Técnicas detalladas – Hay muchas técnicas de
planificación y control de probada eficacia que
se pueden utilizar para apoyar las temáticas
de PRINCE2. Ejemplos son: análisis de ruta
crítica (en planificación) y análisis del valor
acumulado (en control de progreso). Estas
técnicas están bien documentadas en otros
lugares. Sólo se describen aquellas técnicas que
tienen un enfoque PRINCE2 específico, por ej.,
la planificación basada en el producto y las
técnicas de revisión de calidad.
■■ Capacidad de Dirección – El liderazgo,
las competencias de motivación y otras
competencias interpersonales son sumamente
importantes en la gestión de proyectos, pero es
imposible codificarlos en un único método. Los
estilos de dirección varían considerablemente
y un estilo que tiene efecto en una situación
podría ser totalmente inapropiado en otra.
El hecho de que es fácil pensar en dirigentes
que han tenido éxito y han adoptado estilos
muy diferentes – desde autocráticos a basados
en consenso – confirma esto. Por este motivo,
PRINCE2 no puede abordar este aspecto de
la gestión de proyectos directamente. Hay
muchos modelos de dirección y programas de
capacitación en competencias interpersonales
que cumplen con esta exigencia.

Glosario común

Modelos Guías

Actualización
pendiente
Portfolio,
Programme
and Project Gateway ® M_o_R ® ITIL®
Portfolio, Office
Programme and (P3O®)
Project
Management
Maturity Model Portfolio Guide (cartera)
(P3M3TM)

MSPTM (programa)

PRINCE2TM
Maturity Model
(P2MM) PRINCE2TM (proyect o )

Figura 1.3 Orientación de OGC sobre mejores prácticas

8 | Introducción

1.7 Beneficios de PRINCE2 ■■ PRINCE2 promueve coherencia en el trabajo

de los proyectos y la habilidad para reutilizar
Antes de presentar la estructura del método vale la
el activo del proyecto; también facilita la
pena revisar los principales beneficios de adoptar el
movilidad del personal y reduce el impacto de
método PRINCE2:
cambios de personal/traspasos de funciones
■■ PRINCE2 incorpora buenas prácticas y gobierno ■■ PRINCE2 es una herramienta de diagnóstico
establecidos y de probada eficacia para la inapreciable que facilita la garantía y la
gestión de proyectos evaluación del trabajo del proyecto, la solución
■■ Se puede aplicar a cualquier tipo de proyecto de problemas y las auditorías
– y se puede implementar con facilidad junto ■■ Hay numerosas organizaciones de formación
con modelos especializados, específicos a una y consultoría acreditadas (Accredited Training
industria (‘modelos de ingeniería’ o ‘ciclos de Organisations y Accredited Consultancy
vida de desarrollo’) Organisations) que operan en todo el mundo
■■ PRINCE2 es ampliamente reconocido y y cuyos expertos pueden proporcionar
comprendido y, por consiguiente, presenta un apoyo para proyectos PRINCE2 o para las
vocabulario común para todos los participantes organizaciones que están planificando adoptar
en un proyecto, promoviendo comunicación PRINCE2.
efectiva
■■ PRINCE2 prevé el reconocimiento explícito
de las responsabilidades del proyecto – de
modo que los participantes comprendan
las necesidades y los roles mutuos. Hay
una estructura definida para roles,
responsabilidades, delegación, autoridad y
comunicación
■■ Al estar centrado en los productos, aclara (para
todas las partes) aquello que un proyecto
entregará, por qué, cuándo, quién lo hará y
para quién
■■ Los planes de PRINCE2 se diseñan
cuidadosamente a fin de satisfacer las
necesidades de diferentes niveles del equipo de
gestión, mejorando la comunicación y el control
■■ Se basa en un marco de ‘gestión por excepción’,
proporcionando el uso eficiente y económico
del tiempo de los dirigentes (ya sea a nivel
corporativo, de programa, de Junta de Proyecto
o de gestión del proyecto)
■■ PRINCE2 asegura que los participantes centren
su atención en la viabilidad del proyecto en
función de los objetivos de su Business Case
– más bien que en ver la terminación del
proyecto como un fin en sí mismo
■■ Define una estructura completa pero económica
de informes
■■ Asegura que las partes interesadas (incluidos los
patrocinadores y los proveedores de recursos)
estén debidamente representados en la
planificación y la toma de decisiones
■■ Adoptar PRINCE2 promueve el aprendizaje y
mejoras continuas en las organizaciones
Principios 2
2 Principios
El propósito de PRINCE2 es proveer un método de
gestión de proyectos que se puede aplicar sin tener
en cuenta el tamaño, el tipo, la organización, la
ubicación geográfica o la cultura del proyecto. Esto
es posible porque PRINCE2 se basa en principios.
Los principios se caracterizan por ser:
■■ Universales ya que son de aplicación a cada
proyecto
■■ Autovalidantes ya que han sido probados en la
práctica durante varios años
■■ Empoderadores ya que dan a los practitioners
que utilizan el método mayor confianza y
habilidad para determinar e influir en la
manera en que el proyecto se gestionará.
Los principios en los cuales PRINCE2 se basa tienen
su origen en las lecciones aprendidas de proyectos
tanto buenos como malos. Proporcionan un marco
de buenas prácticas para aquellos que participan
en un proyecto. Si un proyecto no es fiel a estos
principios, no se está gestionando utilizando
PRINCE2, porque los principios son la base de
aquello que define un Proyecto PRINCE2.
Los siete principios de PRINCE2 se pueden resumir
a saber:
■■ Justificación comercial continua
■■ Aprender de la experiencia
■■ Roles y responsabilidades definidos
■■ Gestión por fases
■■ Gestión por excepción
■■ Enfoque en los productos
■■ Adaptación para corresponder al entorno del
proyecto.
Es la adopción de estos principios lo que caracteriza
si un proyecto está utilizando PRINCE2, no
solamente la adopción de procesos y documentos.
Los principios facilitan el buen uso de PRINCE2
al asegurar que el método no se aplique de una
manera demasiado prescriptiva o sólo de nombre,
sino que se aplique de una manera suficiente para
contribuir al éxito del proyecto.
2.1 Justificación comercial
continua
Un proyecto PRINCE2 tiene justificación
comercial continua.
Una exigencia para un proyecto PRINCE2 es que:
■■ Haya un motivo justificable para iniciarlo
■■ La justificación se mantenga válida durante
toda la vida del proyecto
■■ La justificación se documente y se apruebe.
En PRINCE2, la justificación se documenta
en un Business Case. Como un proyecto está
intrincadamente relacionado con su justificación
comercial, impulsa los procesos de toma de
decisiones para asegurar que el proyecto se
mantenga alineado con los objetivos comerciales y
los beneficios esperados.
Las organizaciones carentes de rigor cuando se
trata de desarrollar los Business Cases podrían
descubrir que algunos proyectos siguen adelante
aun cuando hay pocos beneficios reales o cuando
un proyecto sólo tiene asociaciones provisionales
con la estrategia corporativa. La mala alineación
con las estrategias corporativas también puede
hacer que las organizaciones tengan una cartera
de proyectos cuyos objetivos son mutuamente
contradictorios o se duplican.
Aun los proyectos que son obligatorios (por
ejemplo, para cumplir con legislación nueva)
requieren justificación de la opción elegida, ya
que podría haber varias opciones disponibles con
diferentes costes, beneficios y riesgos.
Si bien la justificación se debería mantener
válida, puede cambiar. Por eso es importante
que el proyecto y la justificación en desarrollo se
mantengan consecuentes.
Si, por cualquier motivo, el proyecto ya no se
puede justificar, se debería detener el proyecto.
Detener un proyecto en estas circunstancias es una
contribución positiva a una organización ya que
sus fondos y recursos se podrán reinvertir en otros
proyectos más valiosos.
12 | Principios
2.2 Aprender de la experiencia
Los equipos de proyectos PRINCE2 aprenden
de experiencias previas: las lecciones se buscan,
se hacen constar y se obra en consecuencia
durante toda la vida del proyecto.
Los proyectos suponen una organización
temporal durante un calendario limitado para un
propósito comercial específico. Una característica
común es que el proyecto incluye un elemento
de singularidad de modo tal que no puede ser
gestionado por la gerencia de línea existente ni
por unidades funcionales. Es este elemento de
singularidad lo que hace que los proyectos sean
desafiantes, ya que el equipo temporal podría no
tener experiencia de un proyecto como el que se
está realizando.
En PRINCE2, aprender de la experiencia impregna
el método:
■■ Al iniciar un proyecto - Se deberían revisar los
proyectos anteriores o similares para ver si las
lecciones aprendidas se podrían aplicar. Si es la
primera vez que el personal de la organización
realiza un proyecto de este tipo, es todavía más
importante aprender de la experiencia previa y
el proyecto debería considerar si solicitar pericia
externa
■■ A medida que el proyecto progresa - El
proyecto debería continuar aprendiendo.
Las lecciones se deberían incluir en todos los
informes y revisiones. El objetivo es buscar
oportunidades para implementar mejoras
durante la vida del proyecto
■■ A medida que el proyecto cierra - El proyecto
debería comunicar las lecciones. A menos que
las lecciones provoquen cambios, sólo son
lecciones identificadas (no aprendidas).
Todos los que participan en el proyecto son
responsables de buscar las lecciones aprendidas
y no deberían esperar a que otra persona se las
suministre.
2.3 Roles y responsabilidades
definidos
Un proyecto PRINCE2 tiene roles y
responsabilidades definidos y convenidos en
una estructura organizativa que cuadra con
los intereses comerciales de la empresa, de
los usuarios y de los proveedores como partes
interesadas.
Los proyectos dependen de la participación de
la gente. Por más que haya buena planificación
o control, esto no será de ayuda si la gente que
participa no es apropiada, si la gente apropiada no
participa o si la gente que participa no sabe qué se
espera de ellos o qué esperar de otros.
Por regla general un proyecto es interfuncional,
podría atañer a más de una organización y también
podría atañer a una mezcla de recursos con
dedicación exclusiva o a tiempo parcial. Es probable
que las estructuras de gestión de las partes que
intervienen en el proyecto sean diferentes y tengan
diferentes prioridades, objetivos e intereses que
buscan proteger. Las estructuras de gerencia de
línea de todos los días podrían no estar diseñadas
para el trabajo de proyecto ni prestarse para ello.
Para tener éxito, los proyectos deben tener una
estructura del equipo de gestión del proyecto
explícita que consista en roles y responsabilidades
definidos y convenidos para la gente que participa
en el proyecto y un medio de comunicación
efectivo entre ellos.
Todos los proyectos tienen las siguientes partes
interesadas primarias:
■■ Patrocinadores ‘comerciales’ que endosan los
objetivos y aseguran que la inversión comercial
tenga una buena relación calidad-precio
■■ ‘Usuarios’ que, una vez que el proyecto se
ha completado, utilizarán los productos para
permitirles obtener los beneficios esperados
 Principios | 13

■■ ‘Proveedores’ que proporcionan la pericia y La planificación sólo se puede hacer hasta un

los recursos requeridos por el proyecto (éstos
podrían ser internos o externos).
Por consiguiente, los intereses de las tres partes
interesadas deben estar representados con
efectividad en el equipo de gestión del proyecto
– dos de tres no es suficiente. Si los costes del
proyecto son mayores que los beneficios, el
proyecto fracasará. De la misma manera, si el
resultado final del proyecto no satisface las
necesidades operacionales o las necesidades de los
usuarios, o los proveedores no lo pueden entregar
de forma realista, el fracaso es inevitable.
La estructura del equipo de gestión del proyecto
definida une a las diversas partes bajo las
finalidades comunes del proyecto. Para todas las
personas que participan, una estructura del equipo
de gestión del proyecto definida proporciona la
respuesta a la pregunta: ‘¿Qué se espera de mí?’
2.4 Gestión por fases
Un proyecto PRINCE2 se planifica, se supervisa y
se controla fase por fase.
nivel de detalle que sea razonable y previsible. Se
puede desperdiciar gran cantidad de esfuerzo en
intentos de planificar más allá de un horizonte
de planificación sensato. Por ejemplo, un plan
detallado que muestre lo que cada miembro del
equipo estará haciendo en los 12 meses siguientes
casi con seguridad será inexacto tan sólo después
de unas pocas semanas. Desarrollar un Plan del
Equipo detallado a corto plazo y un plan preliminar
a largo plazo es un enfoque más efectivo.
PRINCE2 resuelve la cuestión del horizonte de
planificación al:
■■ Dividir el proyecto en una serie de fases de
gestión
■■ Tener un Plan de Proyecto de alto nivel y un
Plan de la Fase actual detallado
■■ Planificar, delegar, supervisar y controlar el
proyecto fase por fase.
PRINCE2 requiere que haya un mínimo de dos fases
de gestión: una fase de inicio y una o más fases de
gestión adicionales.

Las fases de gestión proporcionan al personal

directivo superior puntos de control en los
principales intervalos durante todo el proyecto. Al
final de cada fase se debería evaluar el estado del
proyecto, revisando el Business Case y los planes
para asegurar que el proyecto se mantiene viable y
para que se pueda tomar una decisión en cuanto a
si ha de proceder.
Desglosar el proyecto en una serie de fases permite
variar el alcance del control del personal directivo
superior sobre los proyectos en función de su
prioridad comercial, del riesgo y de la complejidad.
Las fases más cortas ofrecen más control, mientras
que las fases más largas reducen el peso de la
responsabilidad para el personal directivo superior.
14 | Principios
2.5 Gestión por excepción
Un proyecto PRINCE2 tiene tolerancias definidas
para cada objetivo del proyecto a fin de
establecer límites de autoridad delegada.
PRINCE2 permite el gobierno apropiado al definir
responsabilidades bien diferenciadas para la
dirección, gestión y entrega del proyecto y al
definir con claridad las responsabilidades a cada
nivel. Las responsabilidades se establecen al:
■■ Delegar autoridad de un nivel de gestión al
siguiente al fijar tolerancias para seis objetivos
para el nivel del plan correspondiente:
●● Tiempo – Más o menos un período de
tiempo respecto de las fechas límite de
terminación
●● Coste - Más o menos un monto del
presupuesto planificado
●● Calidad - Más o menos una desviación
respecto de una meta de calidad (por ej., un
producto que se prevé pesará 300 g, con una
tolerancia permitida de -5 g a +10 g)
●● Alcance – Variación permisible de los
productos del plan (por ej., exigencias
obligatorias más o menos exigencias
deseables)
●● Riesgo – Límites respecto de los riesgos
totales del plan (por ej., los coste de las
amenazas totales han de ser inferiores al
10% del presupuesto del plan) o límites a
cualquier amenaza individual (por ej., una
amenaza a un servicio operacional)
●● Beneficio - Más o menos una desviación
respecto de una meta de mejora (por ej.;
reducción de coste de 30–40%)
■■ Fijar controles de modo que si se prevé que
se excederán esas tolerancias, se involucre de
inmediato al nivel de gestión siguiente para
que tomen una decisión sobre la manera de
proceder
■■ Implementar un mecanismo de garantía de
modo que cada nivel de gestión pueda tener
confianza en que dichos controles son efectivos.
Esta implementación de ‘gestión por excepción’
prevé un uso muy eficiente del tiempo del personal
directivo superior ya que reduce la carga de
tiempo de dicho personal sin eliminar su control
al asegurar que las decisiones se tomen al nivel
correcto en la organización.
2.6 Enfoque en los productos
Un proyecto PRINCE2 centra su atención en
la definición y la entrega de productos; en
particular, en sus exigencias de calidad.
Un proyecto exitoso está orientado a los resultados,
no a las actividades. Un proyecto orientado a
los resultados es uno que acuerda y define los
productos del proyecto antes de realizar las
actividades requeridas para producirlos. El conjunto
de productos convenidos define el alcance de un
proyecto y proporciona la base para la planificación
y el control.
El propósito de un proyecto es satisfacer las
expectativas de las partes interesadas de
conformidad con la justificación comercial y, para
hacer esto, todos deben comprender los productos
requeridos y las expectativas de calidad para ellos.
El propósito de un proyecto se puede interpretar
de muchas maneras diferentes a menos que haya
comprensión explícita de los productos que se han
de producir y de los criterios en base a los cuales se
aprobarán individualmente.
Un proyecto PRINCE2 utiliza Descripciones de
Productos para ofrecer un alto nivel de claridad al
definir el propósito, la composición, la derivación,
el formato, los criterios de calidad y el método de
calidad de cada producto. Éstas proporcionan un
medio para determinar los cálculos de esfuerzo,
las exigencias de recursos, las dependencias y los
cronogramas para las actividades.
El ‘enfoque en los productos’ apoya casi todos
los aspectos de PRINCE2: la planificación, las
responsabilidades, los informes de estado, la
calidad, el control de cambios, el alcance, la gestión
de la configuración, la aceptación de los productos
y la gestión del riesgo.
Sin un enfoque en los productos, los proyectos
están expuestos a varios riesgos principales
tales como disputas de aceptación, repetición
del trabajo, cambio descontrolado (‘aumento
del alcance’ o scope creep), insatisfacción de los
usuarios y subestimación de las actividades de
aceptación.
 Principios | 15

2.7 Adaptación para corresponder

al entorno del proyecto

PRINCE2 se adapta para corresponder al

entorno, tamaño, complejidad, importancia,
capacidad y nivel de riesgo del proyecto.

El valor de PRINCE2 se basa en que es un método

universal de gestión de proyectos que se puede
aplicar sin importar el tipo, organización, ubicación
geográfica o cultura del proyecto. Se puede utilizar
en cualquier proyecto porque ha sido diseñado
para adaptarse a sus necesidades específicas.
Si PRINCE2 no se adapta, es poco probable que
el enfoque y el esfuerzo de gestión del proyecto
sean apropiados para las necesidades del proyecto.
Esto puede resultar en una gestión del proyecto
‘robotizada’ en un extremo (se sigue el método
sin hacer preguntas) o en gestión del proyecto
‘heroica’ en el otro extremo (no se sigue el método
para nada).
El propósito de la adaptación es:
■■ Asegurar que el método de gestión del
proyecto se relacione con el entorno del
proyecto (por ej., al alinear el método a los
procesos comerciales que podrían regir y apoyar
el proyecto, tales como recursos humanos,
finanzas y adquisiciones)
■■ Asegurar que los controles del proyecto se
basen en el tamaño, complejidad, importancia,
capacidad y nivel de riesgo del proyecto (por ej.,
la frecuencia y formalidad de la presentación de
informes y de las revisiones).
La adaptación requiere que el Project Manager
y la Junta de Proyecto tomen una decisión activa
sobre la manera en que el método se aplicará,
para lo cual se proporciona orientación. Al adaptar
PRINCE2, es importante recordar que requiere
información (no necesariamente documentos) y
decisiones (no necesariamente reuniones).
Para asegurar que todas las personas que
participan en el proyecto comprendan la manera
en que PRINCE2 se ha de utilizar, la Documentación
de Inicio del Proyecto debería indicar la manera
en que el método se está adaptando para ese
proyecto en particular.
 Introducción a las
temáticas de PRINCE2 3
3 Introducción a las temáticas de PRINCE2
3.1 ¿Qué son las temáticas?
Las temáticas de PRINCE2 describen aspectos de
la gestión del proyecto que se deben abordar
continuamente. Cualquier Project Manager que
preste atención rigurosamente a estas temáticas
desempeñará el rol con seriedad profesional.
Sin embargo, la solidez de PRINCE2 se basa en
la manera en que las siete temáticas se integran
y esto se logra debido al tratamiento específico
que PRINCE2 da a cada temática, es decir, se han
diseñado cuidadosamente para vincularse entre sí
con efectividad.
Los procesos de PRINCE2 abordan el flujo
cronológico del proyecto, con acciones relacionadas
con diferentes temáticas mezcladas unas con
otras. Aquí se hace resaltar la secuencia lógica
de cada temática y se proporciona orientación
más detallada a fin de ampliar las actividades de
los procesos. En la Tabla 3.1 se indican las siete
temáticas de PRINCE2 y el capítulo pertinente.

Tabla 3.1 Las temáticas de PRINCE2

Temática Descripción Contesta al Capítulo

Business El proyecto se inicia con una idea que se considera tiene valor potencial ¿Por qué? 4
Case para la organización en cuestión. Esta temática aborda la manera en que
la idea se desarrolla para convertirse en una proposición de inversión viable
para la organización y la manera en que la gestión del proyecto mantiene la
atención en los objetivos de la organización durante todo el proyecto.
Organización La organización patrocinadora del proyecto necesita asignar el trabajo ¿Quién? 5
a gerentes capaces de asumir la responsabilidad y la dirección del
proyecto hasta su terminación. Los proyectos son interfuncionales y, por
consiguiente, las estructuras jerárquicas normales de la organización no
son necesariamente apropiadas. Esta temática describe los roles y las
responsabilidades en el equipo temporal de gestión del proyecto PRINCE2
que se requieren para gestionar el proyecto con efectividad.
Calidad La idea inicial sólo se comprenderá a grandes rasgos. Esta temática ¿Qué? 6
explica la manera en que la idea inicial se desarrolla de modo que todos
los participantes comprendan los atributos de calidad de los productos a
entregar – y luego la manera en que la gestión del proyecto asegurará que
estas exigencias se entreguen posteriormente.
Planes Los proyectos PRINCE2 proceden en base a una serie de planes aprobados. ¿Cómo? 7
Esta temática complementa la temática de la Calidad al describir los pasos
requeridos para desarrollar los planes y las técnicas de PRINCE2 que se ¿Cuánto?
deberían aplicar. En PRINCE2, los planes se hacen corresponder a las
necesidades del personal en los diversos niveles de la organización. Son el
foco de la comunicación y del control durante todo el proyecto.
¿Cuándo?
Riesgo Típicamente, los proyectos conllevan más riesgo que la actividad operacional ¿Qué pasa si…? 8
estable. Esta temática aborda la manera en que la gestión del proyecto
gestiona las incertidumbres en sus planes y en el entorno de proyecto más
amplio.
Cambio Esta temática describe la manera en que la gestión del proyecto evalúa y ¿Cuál es el 9
actúa sobre las cuestiones que tienen un posible impacto en cualquiera de impacto?
los aspectos baseline del proyecto (sus planes y/o productos completados).
Las cuestiones pueden ser problemas generales no anticipados, solicitudes
de cambio o instancias en las que la calidad ha fallado.
Progreso Esta temática aborda la viabilidad continua de los planes. La temática explica ¿Dónde 10
el proceso de toma de decisiones para aprobar planes, el seguimiento del estamos ahora?
rendimiento real y el proceso de presentación de excepciones si los eventos
no salen según lo indicado en el plan. En última instancia, la temática de ¿Adónde
Progreso determina si el proyecto debería proceder y de qué manera. vamos?
¿Deberíamos
continuar?
20 | Introducción a las temáticas de PRINCE2
3.2 Aplicación de las temáticas
Las siete temáticas se deben aplicar en un proyecto
pero se deberían adaptar en función del tamaño,
la naturaleza y la complejidad del proyecto en
cuestión.
Las temáticas se pueden adaptar por exceso
o por defecto, es decir, se puede introducir
documentación detallada adicional y disciplina de
proceso para proyectos complejos o de alto riesgo,
mientras que para proyectos simples de riesgo bajo
las presentaciones concisas de puntos utilizando
viñetas y procesos más informales podrían ser
adecuadas.
3.3 Formato de las temáticas
Cada uno de los capítulos sobre temáticas está
estructurado de la siguiente manera:
■■ Propósito - Por qué es importante para la
entrega exitosa del proyecto
■■ Temática definida - Términos y definiciones
utilizados
■■ El enfoque de PRINCE2 a la temática –
El tratamiento específico del aspecto particular
de la gestión del proyecto que se requiere para
que los procesos de PRINCE2 sean totalmente
efectivos
■■ Responsabilidades - Específicas a la temática
principal para cada rol de PRINCE2.
Business Case 4
4 Business Case

4.1 Propósito En PRINCE2, el Business Case se desarrolla al

comienzo del proyecto, se mantiene durante
El propósito de la temática del Business Case toda la vida del proyecto y pasa por verificaciones
es establecer mecanismos para juzgar si el formales por parte de la Junta de Proyecto en
proyecto es (y se mantiene) deseable, viable y cada punto de toma de decisiones principal, tal
alcanzable como un medio para apoyar la toma como las evaluaciones al final de las fases. Los
de decisiones en su inversión (continua). beneficios se confirman a medida que comienzan a
acumularse. En algunos casos el proyecto se podría
Que un proyecto debe tener una justificación iniciar con un Business Case preexistente (de la
comercial continua es un principio de PRINCE2. gestión corporativa o del programa), en cuyo caso
se perfeccionará durante el inicio.
La justificación comercial es la razón para el
proyecto. Ningún proyecto se debe iniciar sin ésta.
Si la justificación comercial es válida al iniciarse 4.2 Definición del Business Case
un proyecto, pero desaparece una vez que está en
curso, se debe detener o cambiar el proyecto. 4.2.1 ¿Qué es un Business Case?
El Business Case presenta la mezcla óptima de
En PRINCE2, la justificación comercial se documenta
información utilizada para juzgar si el proyecto es
en un Business Case, que describe las razones para
(y se mantiene) deseable, viable y alcanzable y, por
el proyecto en base a los costes estimados, los
consiguiente, algo en que vale la pena invertir.
riesgos y los beneficios esperados.
La Junta de Proyecto y las partes interesadas
Las razones para realizar el proyecto deben
deben tener confianza en todo momento en que
impulsar la toma de decisiones. Cuando los
el proyecto se mantiene viable. En PRINCE2, el
proyectos se enfrentan a cambios o riesgos, el
Business Case proporciona la prueba vital de la
análisis de impacto debe concentrarse en el
viabilidad del proyecto. Facilita la respuesta a la
Business Case, recordando que el proyecto es sólo
pregunta: ¿merece todavía la pena invertir en este
un medio para lograr una finalidad y no es la
proyecto?
finalidad en sí misma.
Debido a que esta pregunta sobre la viabilidad
La decisión continua y siempre presente respecto
es continua, el Business Case no es estático. No
del Business Case consiste en determinar si el
se debe utilizar sólo para obtener la financiación
proyecto todavía se puede justificar. Esto se basa
inicial para un proyecto, sino que se debe
en la premisa de si el proyecto es deseable (el
mantener activamente durante toda la vida del
equilibrio entre coste/beneficio/riesgo), viable
proyecto y se debe actualizar continuamente con
(el proyecto puede entregar los productos) y
la información más reciente sobre costes, riesgos y
alcanzable (los productos pueden proporcionar los
beneficios.
beneficios).
Al tomar decisiones sobre inversiones es
El o los Usuarios Principales son responsables
importante establecer qué beneficios se pueden
de especificar los beneficios y posteriormente
obtener cuándo, con qué nivel de riesgo y desde
de realizar los beneficios mediante el uso de los
qué nivel de inversión. Los proyectos se deben
productos provistos por el proyecto. El Ejecutivo es
evaluar en base a lo bien que contribuirán a
responsable de asegurar que aquellos beneficios
los objetivos corporativos. Este análisis permite
especificados por el o los Usuarios Principales
comparar un proyecto con otro de modo que la
representen una buena relación calidad-precio,
organización pueda elegir invertir en el mejor
estén alineados con los objetivos corporativos y se
conjunto de proyectos.
puedan realizar.
24 | Business Case

4.2.2 Resultados, resultados finales y
beneficios
En PRINCE2:
■■ El resultado de un proyecto es cualquiera de
los productos especializados del proyecto (sean
tangibles o intangibles)
■■ Un resultado final es la consecuencia del
cambio derivado del uso de los resultados del
proyecto
■■ Un beneficio es la mejora medible que se
obtiene de un resultado final que es percibido
como una ventaja por una o más partes
interesadas.
Ejemplo de resultado, resultado final y
beneficios
Resultado: Nuevo sistema de ventas
Resultado final: Los pedidos de venta se
procesan con mayor rapidez y exactitud
Beneficios: Los costes se reducen en un 10%, el
volumen de los pedidos de venta se incrementa
en un 15% y los ingresos aumentan en un 10%
por año.
Debido a que los resultados finales del proyecto y
los beneficios a menudo sólo se realizan después
del cierre del proyecto, lamentablemente es
fácil que el enfoque de los proyectos se centre
únicamente en torno a la creación de productos
(los resultados). El vínculo entre los resultados del
Resultados
del proyecto
proyecto y los resultados finales y los beneficios
se debe identificar con claridad y debe ser visible
para quienes participan ya que, de lo contrario,
se podría perder de vista el propósito original del
proyecto (Figura 4.1).
4.2.3 Tipos de Business Case
Las razones para realizar proyectos varían
enormemente y en gran medida están impulsadas
por su entorno. La naturaleza del proyecto
determinará los objetivos que se utilizarán para
verificar la deseabilidad del proyecto y, más
adelante, para confirmar que los productos
del proyecto hayan logrado esos objetivos.
Estos objetivos se medirán de forma diferente
dependiendo del tipo de proyecto, por ejemplo:
■■ Proyecto obligatorio
■■ Proyecto sin fines de lucro
■■ Proyecto en evolución
■■ Proyecto en entorno cliente/proveedor
■■ Proyecto para múltiples organizaciones.
Algunos de estos proyectos se podrían medir
principalmente en base al ‘retorno sobre la
inversión’, pero otros (especialmente los proyectos
obligatorios o sin fines de lucro) se podrían medir
en base a otros beneficios no financieros.
Sin importar el tipo de medida que se está
utilizando, queda la pregunta: para este nivel
de inversión, ¿son los beneficios anticipados más
deseables, viables y alcanzables que las otras
opciones disponibles? Para más información sobre
la manera en que el entorno del proyecto afecta el
Business Case, véase el Capítulo 19.

permiten
4.3 El enfoque del Business Case
crean
Resultados
según PRINCE2
Cambios
comerciales finales
deseados En PRINCE2, el Business Case se desarrolla al
también iniciarse el proyecto y se mantiene durante toda la
causan medidos en
función de vida del proyecto, es formalmente verificado por
la Junta de Proyecto en cada punto de decisión
Efectos principal tal como las evaluaciones al final de fases
secundarios y
consecuencias realizan Beneficios y se confirma durante todo el período en que se
otros
acumulan los beneficios.
provocan ayudan a
lograr uno o más En este contexto:

Contrabeneficios Objetivos ■■ Desarrollar significa obtener la información

estratégicos correcta en base a la cual se pueden tomar
decisiones
Figura 4.1 Relación entre resultados, resultados ■■ Verificar significa evaluar si el proyecto
finales y beneficios (todavía) vale la pena

■■ Mantener significa actualizar el Business Case
con costes y beneficios reales y las previsiones
actuales para costes y beneficios
■■ Confirmar significa evaluar si los beneficios
esperados se han realizado (o se realizarán). La
confirmación de beneficios tendrá lugar en su
mayor parte post-proyecto.
Cualquier evaluación del impacto de riesgos,
cuestiones y cambios gira en torno al Business
Case al formular la pregunta: ¿de qué manera
afectará este riesgo, cuestión o cambio la viabilidad
del Business Case y los objetivos y beneficios
comerciales que se están tratando de lograr?
4.3.1 Desarrollo del Business Case
En PRINCE2 el Ejecutivo es responsable del Business
Case. Esto no significa necesariamente que el
Ejecutivo redacte el Business Case, simplemente
que el Ejecutivo es responsable de asegurar que el
Business Case se cree y se apruebe.
El desarrollo del Business Case se podría delegar,
por ejemplo, a un analista comercial o quizás aun
al Project Manager. En algunos casos, la gestión
del programa suministrará un Business Case
aprobado como parte del Expediente del Proyecto.
Cualquiera sea la persona a quien se asigna la
tarea de desarrollar el Business Case, es importante
asegurar que ésta tenga las competencias
comerciales apropiadas que se requieren (por
ejemplo, comprender la diferencia entre una
previsión de flujo de caja, una cuenta de pérdidas y
ganancias y un balance). De no ser así, la Junta de
Proyecto debe considerar el uso de la Garantía del
Proyecto para ayudar con el desarrollo del Business
Case.
Pre- Fase de Fase(s) de entrega
proyecto inicio subsiguiente(s)
Verificar el Verificar el
Business Case Business Case
preliminar detallado
Desarrollar el
Business Case
Figura 4.2 La ruta de desarrollo del Business Case
Business Case | 25
El Business Case preliminar se deriva del mandato
de proyecto y se desarrolla antes del proyecto,
durante el proceso de la Puesta en Marcha de un
Proyecto a fin de obtener durante el proceso de la
Dirección de un Proyecto la aprobación de la Junta
de Proyecto para iniciar el proyecto.
El Business Case detallado se deriva del Business
Case preliminar, del Plan de Proyecto (costes,
calendario, productos) y del Registro de Riesgos.
Debido a los aportes requeridos para desarrollar
un Business Case, su desarrollo será iterativo.
Es necesario que haya una justificación inicial
para proceder con el proyecto, pero hasta que el
proyecto se planifique en detalle, el Business Case
preliminar se basa en costes y en calendarios que
son, como mucho, aproximados. Una vez que los
costes y los calendarios se comprenden mejor, esto
podría incrementar o disminuir la deseabilidad,
viabilidad y capacidad de consecución del proyecto
y podría por lo tanto cambiar el enfoque del
proyecto, llevando a una cierta replanificación.
4.3.2 Verificación y mantenimiento del
Business Case
El Business Case impulsa toda la toma de decisiones
al asegurar que el proyecto mantenga su
justificación y que los objetivos comerciales y los
beneficios que se buscan se puedan realizar.
Para impulsar la toma de decisiones, el Business
Case debe someterse a revisión:
■■ Por la Junta de Proyecto al final del proceso de
la Puesta en Marcha de un Proyecto a fin de
que se autorice el inicio del proyecto en base a
una justificación razonable
Confirmar los Confirmar los Confirmar los
beneficios beneficios beneficios
Fase de entrega
Post-proyecto
final
Verificar el
Business Case
actualizado
Mantener el
Business Case
26 | Business Case
■■ Por la Junta de Proyecto al final del proceso
del Inicio de un Proyecto a fin de autorizar el
proyecto
■■ Por el Project Manager como parte de cualquier
evaluación del impacto de cualquier cuestión o
riesgo nuevos o revisados
■■ Por la Junta de Proyecto conjuntamente con
un Plan de Excepción a fin de autorizar la fase
revisada y la continuación del proyecto
■■ Por el Project Manager al final de cada fase
a fin de determinar si es necesario actualizar
cualquiera de los costes, calendarios, riesgos o
beneficios
■■ Por la Junta de Proyecto al final de cada
fase a fin de autorizar la fase siguiente y la
continuación del proyecto
■■ Por el Project Manager durante la fase final
a fin de evaluar el rendimiento del proyecto
en función de sus exigencias y la probabilidad
de que los resultados finales proporcionen los
beneficios esperados
■■ Posiblemente por la gestión corporativa o
del programa como parte de la revisión de
beneficios a fin de determinar si los resultados
finales del proyecto lograron hacer realidad sus
beneficios.
El Ejecutivo es responsable de asegurar a las partes
interesadas que el proyecto se mantiene deseable,
viable y alcanzable en todo momento. El Ejecutivo
no debe depender de las evaluaciones al final de
fase solamente para hacer este juicio y debe utilizar
a la Garantía del Proyecto para obtener asistencia.
La sección sobre evaluación de la inversión del
Business Case proporciona a la Junta de Proyecto
la fuente de información para verificar que
el Business Case justifique la autorización o
continuación del proyecto.
Ejemplo de un Business Case no verificado
Un proyecto de construcción de una atracción
turística en Londres, subvencionado por el
gobierno, se justificó en base a que atraería a
12 millones de visitantes en su primer año. La
cantidad de visitantes prevista determinó la
proyección de los ingresos para la exhibición. Al
estar el equipo a cargo del proyecto presionado
para construir una ‘exhibición de clase mundial’,
el presupuesto para el proyecto se fijó a un
umbral de rentabilidad basado en 11 millones
de visitantes. La cantidad de 12 millones de
visitantes previstos era una suposición no
comprobada y considerablemente superior a
la cifra real de 4,5 millones de visitantes. En
términos clásicos de proyecto, todo fue un
éxito: la exhibición abrió a tiempo, estuvo
dentro del 5% del presupuesto de coste y contó
con todas las instalaciones que se solicitaron
y por consiguiente cumplió los criterios de
aceptación. Sin embargo, el desnivel en la
cantidad de visitantes comportó ingresos
considerablemente menores, lo cual significó
que la subvención gubernamental necesaria
aumentó de £399 millones a £628 millones. En
términos comerciales y de relaciones públicas
fue un desastre que demostró que la entrega de
un proyecto a tiempo, dentro de los márgenes
del presupuesto y conforme a especificaciones
basadas en suposiciones poco sólidas en lo
que respecta a los beneficios niega la entrega
exitosa de un proyecto.
4.3.3 Confirmación de los beneficios
El enfoque para confirmar beneficios consiste en:
■■ Identificar los beneficios
■■ Seleccionar medidas objetivas que demuestren
los beneficios con fiabilidad
■■ Recoger las medidas baseline (a partir de las
cuales se cuantificarán las mejoras)
■■ Decidir cómo, cuándo y quién recogerá las
mediciones de los beneficios.
El o los Usuarios Principales especifican los
beneficios y son responsables de demostrar a
la gestión corporativa o del programa que los
beneficios previstos que formaron la base de la
aprobación del proyecto se han de hecho realizado.
Esto podría significar un compromiso más allá de la

vida del proyecto, ya que es probable que muchos
beneficios no se realicen hasta después de que el
proyecto haya cerrado.
Esto plantea un dilema porque, una vez que el
proyecto cierra, la ‘organización temporal’ se
disuelve junto con el marco (y en particular la
financiación y los recursos) para realizar cualquier
actividad de medición.
PRINCE2 soluciona este dilema al definir un Plan
de Revisión de Beneficios. El Plan de Revisión de
Beneficios del proyecto utilizará el Business Case
detallado para definir el alcance, el calendario y la
responsabilidad de una serie de revisiones en base
a la oportunidad y la naturaleza de los beneficios
esperados.
Por defecto, el Ejecutivo es responsable de asegurar
que las revisiones de beneficios se planifiquen y se
ejecuten, pero hay circunstancias en las cuales éste
no siempre será el caso:
■■ Para proyectos en un entorno de programa,
el programa podría producir y ejecutar el Plan
de Revisión de Beneficios del proyecto, ya que
uno de los roles del programa es coordinar la
realización de los beneficios de sus proyectos
■■ Si la organización corporativa tiene un centro
de excelencia u otro tipo de unidad de
seguimiento del rendimiento, podría asumir
la responsabilidad de la medición de los
beneficios de todos los proyectos dentro de la
organización
■■ Para actividades de medición post-proyecto,
la responsabilidad de las revisiones de
beneficios se transferirá del Ejecutivo a la
gestión corporativa o del programa al cerrarse
el proyecto (ya que será necesario financiar y
asignar recursos a las revisiones).
El Project Manager es quien crea el Plan de
Revisión de Beneficios en primera instancia en la
fase de inicio y lo presenta a la Junta de Proyecto
para su aprobación al solicitar la autorización del
proyecto. Si la gestión corporativa o del programa
ha de gestionar las revisiones de beneficios o
participar en éstas, quizás sea necesario que la
Junta de Proyecto solicite la aprobación de la
gestión corporativa o del programa. El Plan de
Revisión de Beneficios se actualiza hacia el final
de cada fase con los beneficios reales logrados y
se crea un plan revisado para cualquier revisión
pendiente, ya sea dentro o más allá de la vida del
proyecto.
Business Case | 27
Debido a que el proyecto o la gestión corporativa
o del programa podrían gestionar el Plan de
Revisión de Beneficios, PRINCE2 recomienda que se
mantenga separado del Plan de Proyecto y de los
Planes de Fase.
Los beneficios que se pueden medir durante la
vida de un proyecto deben ser notificados por el
Project Manager en el Informe al Final de Fase.
Cualquier beneficio residual se debe reexaminar
y su previsión se debe actualizar como parte del
proceso de la Gestión de los Límites de Fase.
La o las revisiones de beneficios post-proyecto
implicarán que la gestión corporativa o del
programa responsabilizarán al o a los Usuarios
Principales, al solicitarles que aporten pruebas de
la manera en que los beneficios individuales que
les fueron asignados a ellos se han obtenido en
comparación con aquellos beneficios prometidos,
para justificar el coste y el riesgo del proyecto
cuando se autorizó. La o las revisiones de
beneficios post-proyecto también revisarán el
rendimiento de los productos del proyecto en
uso operacional e identificarán si se ha producido
cualquier efecto secundario (beneficioso o adverso)
que pueda proporcionar lecciones provechosas
para otros proyectos.
4.3.4 El contenido de un Business Case
El Business Case debe describir las razones para
realizar el proyecto en base a costes estimados,
riesgos y beneficios esperados. Por lo general
contiene:
■■ Un resumen ejecutivo
■■ Razones
■■ Opciones comerciales
■■ Beneficios esperados
■■ Contrabeneficios previstos
■■ Calendario
■■ Costes
■■ Evaluación de la inversión
■■ Riesgos principales.
La Descripción de Producto para un Business Case
se podrá encontrar en el Apéndice A. Las secciones
a continuación proveen más orientación sobre
parte del contenido del Business Case.
28 | Business Case
4.3.4.1 Razones
El Business Case debe explicar las razones por las
cuales se requiere el proyecto. Idealmente, debe
estar vinculado al contexto organizativo y debe
explicar la manera en que el proyecto permitirá
que se logren las estrategias y los objetivos
corporativos.
Es probable que las razones se definan en el
mandato de proyecto. De no ser así, se debe
solicitar aclaración. Por ejemplo, el motivo
para trasladarse a oficinas nuevas podría ser un
cambio en la demografía o mayores costes de
arrendamiento, debido a que la empresa requiere
más espacio o para cumplir con legislación nueva
tal como acceso para discapacitados.
4.3.4.2 Opciones comerciales
Hay tres opciones comerciales básicas respecto de
cualquier inversión:
■■ No hacer nada
■■ Hacer lo mínimo
■■ Hacer algo.
‘No hacer nada’ debe siempre ser la opción inicial
que proporcione la base para cuantificar las otras
opciones – la diferencia entre ‘no hacer nada’ y
‘hacer lo mínimo’/‘hacer algo’ es el beneficio que la
inversión comprará.
El análisis de cada opción proporciona a la Junta
de Proyecto y a las partes interesadas del proyecto
suficiente información para juzgar qué opción
representa el mejor valor para la organización.
Proporciona la respuesta a la pregunta: para este
nivel de inversión, ¿son los beneficios anticipados
más deseables, viables y alcanzables que las otras
opciones disponibles?
Se debe evaluar continuamente la deseabilidad,
la viabilidad y la capacidad de consecución del
Business Case para la opción elegida ya que
cualquier riesgo nuevo y/o cambio podrían hacer
que una de las otras opciones sea más justificable.
4.3.4.3 Beneficios esperados
El Business Case debe enumerar cada beneficio
que se afirma que el resultado final del proyecto
lograría (para la opción comercial seleccionada).
Es importante definir el estado actual de cada
beneficio en términos cuantificables de modo que
se puedan evaluar las mejoras medibles después
de que se haya completado el proyecto. El Business
Case debe definir la manera y el momento en que
se puede medir la mejora. Por ejemplo, uno de los
beneficios del traslado de la oficina podría ser un
ahorro en costes de realizar conferencias en un
hotel, pero sólo si las nuevas instalaciones tienen
más salas de conferencias.
Los beneficios pueden ser financieros y no
financieros (a veces llamados con o sin valor
contable). Sin importar si son financieros o no
financieros, los beneficios deben:
■■ Estar alineados con las estrategias y los
objetivos corporativos
■■ Corresponder a los resultados y a los resultados
finales provistos por el proyecto
■■ Ser cuantificados (con tolerancia)
■■ Ser medibles
■■ Ser asignados.
La responsabilidad clara por los beneficios,
colectiva e individualmente, es una exigencia
principal para la realización de los beneficios.
El o los Usuarios Principales son responsables
del conjunto de beneficios en sus respectivas
áreas, pero la responsabilidad de los beneficios
individuales se debe asignar a una persona
apropiada, idealmente dentro del grupo de
usuarios en que ese beneficio influye.
La lista de beneficios esperados influirá en
el conjunto de productos que el proyecto
suministrará. El proyecto no debe incluir ningún
producto que no permita que se logren, directa
o indirectamente, los beneficios esperados. Hacer
corresponder los productos a los resultados finales
y posteriormente a los beneficios ayuda a tomar
decisiones de planificación y control del proyecto.
Esta correspondencia permite tomar decisiones en
base al impacto de la realización de los beneficios
esperados, es decir, la justificación para realizar el
proyecto.
Dondequiera que sea posible, los beneficios se
deben expresar en formas tangibles. El Usuario
Principal o el Ejecutivo podrían definir muchos
beneficios como intangibles (por ejemplo, ‘personal
más contento’). Vale la pena hacer el esfuerzo
de pensar cuidadosamente sobre los beneficios
intangibles para ver si se pueden expresar de
maneras medibles. En este ejemplo, ‘personal más
contento’ podría traducirse en menor movimiento
de personal y/o menos tiempo sin trabajar debido
a problemas relacionados con el estrés. Ambos
se pueden convertir en un ahorro monetario
probable.
La cuantificación de los beneficios permite fijar
tolerancia de beneficios (por ej., un incremento

del 10–15% en ventas) y la mensurabilidad de los
beneficios asegura que se puedan comprobar. Si
el proyecto incluye beneficios que no se pueden
comprobar, es imposible juzgar si el proyecto:
■■ Ha tenido éxito
■■ Ha tenido una buena relación calidad-precio
■■ Se debe iniciar (o se debería haber iniciado).
Hay muchas maneras de verificar los beneficios
esperados. Por ejemplo, se puede utilizar un
análisis de sensibilidad para determinar si el
Business Case depende en gran medida de un
beneficio determinado. Si es así, esto podría afectar
las actividades de planificación del proyecto, de
seguimiento y control y la gestión del riesgo, ya
que se deberían tomar medidas para proteger ese
beneficio específico.
Otro ejemplo consiste en definir tres
consideraciones sobre el logro de los beneficios, es
decir, ¿qué esperamos en realidad, qué podríamos
lograr si las cosas salen bien y cuál podría ser el
peor de los escenarios? Éste último se podría ver
afectado por la inclusión de un complemento en
los costes para valorar las inexactitudes, cambios
y riesgos. Este análisis por lo general revela si los
beneficios esperados son razonables o demasiado
optimistas. El resultado de este análisis podría
llevar a una revisión de la decisión de seguir
adelante con el proyecto, lo cual a su vez formaría
la base para fijar cualquier tolerancia de beneficios.
Una vez que los beneficios están definidos, se
deben describir en el Plan de Revisión de Beneficios
las actividades para establecer y recoger las
medidas.
4.3.4.4 Contrabeneficios previstos
Un contrabeneficio es un resultado final percibido
como negativo por una o más partes interesadas.
Los contrabeneficios son consecuencias reales de
una actividad mientras que, por definición, un
riesgo presenta una cierta incertidumbre en cuanto
a su concreción.
Por ejemplo, la decisión de fusionar dos elementos
de una organización en un lugar nuevo podría
tener beneficios (por ej., mejor trabajo en
conjunto), costes (por ej., expansión de uno de
dos lugares) y contrabeneficios (por ej., una
disminución en productividad durante la fusión).
Sería necesario considerar y valorar todos ellos
como parte de la evaluación de la inversión.
Business Case | 29
4.3.4.5 Calendario
La gestión corporativa y/o del programa querrá
saber:
■■ El período durante el cual se incurrirá en los
costes del proyecto
■■ El período en el cual se basará el análisis de
costes/beneficios
■■ Cuándo la organización puede esperar
acumular beneficios
■■ Cuál es la fecha de inicio más temprana/tardía
factible
■■ Cuál es la fecha de terminación más temprana/
tardía factible.
Identificar las exigencias de calendario para un
proyecto puede ayudar a identificar tolerancias y
momentos aptos para revisiones de beneficios.
4.3.4.6 Costes
El Business Case debe resumir los costes derivados
del Plan de Proyecto, junto con las suposiciones en
las que se basan. Los costes también deben incluir
detalles de los costes continuos de operaciones y
mantenimiento y los acuerdos para su financiación.
4.3.4.7 Evaluación de la inversión
Con la información en el Business Case, es posible
y necesario comparar los costes de desarrollo,
operaciones y mantenimiento con el valor de
los beneficios durante un período de tiempo (a
menudo llamada una evaluación de la inversión).
El período de evaluación de la inversión podrá
ser una cantidad fija de años o la vida útil de los
productos. La autoridad responsable podría haber
prescrito reglas de contabilidad que definen la
manera en que la inversión se evaluará.
La evaluación de la inversión debe cubrir tanto los
costes del proyecto (para producir los productos
requeridos y los costes de gestión del proyecto)
como los costes continuos de las operaciones y
mantenimiento. Por ejemplo, los costes estimados
para el traslado de una oficina podrían cubrir los
costes del proyecto para las actividades de traslado,
los costes de los artículos de escritorio nuevos, las
multas por terminación de los acuerdos de servicio
en los locales actuales y el incremento en alquiler/
contribuciones municipales y costes de servicios
para la oficina nueva.
30 | Business Case

4.3.4.8 Riesgos principales

Técnicas de evaluación de la inversión
Es probable que cualquier oportunidad se vea
Las técnicas de evaluación de la inversión
contrarrestada por un elemento de riesgo. Por eso,
incluyen:
a fin de emitir un juicio de ‘justificación comercial’,
■■ Costes de por vida – Análisis del coste la Junta de Proyecto necesita comprender no
total de implementación y cualquier coste
sólo los beneficios y los costes del proyecto, sino
adicional de operaciones y mantenimiento
también el conjunto de riesgos que podrían ya
■■ Beneficios netos – Análisis del valor
total de los beneficios menos el coste sea reducir/incrementar los beneficios o reducir/
de implementación y de las operaciones incrementar el coste.
continuas, calculados durante un período de
El Business Case debe incluir un resumen de los
tiempo definido
principales grupos de riesgos (se sugiere que
■■ Retorno sobre la inversión (ROI) – Ganancias
o ahorros resultado de inversiones (esto es lo esto sea bajo la forma de un perfil de riesgo
mismo que beneficios netos si los beneficios resumido) y destacar los riesgos principales que
fuesen sólo financieros) tendrán un efecto en los objetivos comerciales y
■■ Período de reembolso – Cálculo del período en los beneficios, por lo tanto cubriendo tanto la
de tiempo requerido para que el retorno entrega del proyecto como el mantenimiento y
sobre la inversión (ROI) ‘“devuelva” el monto las operaciones continuas. Por ejemplo, los riesgos
de la inversión original
del traslado de la oficina podrían incluir costes
■■ Flujos de efectivo descontado – Un medio
de mudanza imprevistos (por ej., eliminación
para expresar beneficios futuros en base al
valor actual del dinero. A veces, los flujos de amianto) o un impacto en la continuidad del
de fondos actualizados incluyen ajustes de negocio (por ej., pérdida de personal principal no
riesgo ya que el negocio podría no tener dispuesto a trasladarse).
confianza en que todos los beneficios se
materializarán
■■ Valor actual neto – El valor total de los 4.4 Responsabilidades
ingresos financieros futuros descontados En la Tabla 4.1 se explican resumidamente las
menos la inversión original. Por ejemplo, si
responsabilidades pertinentes a la temática del
la inflación es del 6%, el valor del dinero se
reduce a la mitad aproximadamente cada 12 Business Case. Véase el Apéndice C para más
años. Si un proyecto prevé que un beneficio detalles sobre los roles del equipo de gestión del
de 500.000 € se materializará en el año 12, proyecto y sus responsabilidades asociadas.
sólo vale 250.000 € en el dinero de hoy
■■ Análisis de sensibilidad – Los Business Cases
se basan en previsiones inciertas. A fin de
identificar el grado de solidez del Business
Case, es útil comprender la relación entre
los factores de entrada (por ej., costes del
proyecto, calendario, calidad, alcance, riesgo
del proyecto) y de salida (por ej., costes de
operaciones y mantenimiento, beneficios
comerciales y riesgo comercial). El análisis
de sensibilidad implica hacer ajustes en
los factores de entrada para modelar el
punto en el cual los factores de salida ya
no justifican la inversión. Por ejemplo, el
proyecto vale la pena si se puede realizar en
cuatro meses pero deja de valer la pena si
lleva seis meses.
 Business Case | 31

Tabla 4.1 Responsabilidades pertinentes al Business Case

Rol Responsabilidades
Gestión corporativa o Suministrar el mandato de proyecto y definir cualquier norma conforme a la cual el Business
del programa Case se necesita desarrollar.
Responsabilizar al o a los Usuarios Principales de la realización de los beneficios post-proyecto
que surgen de los productos del proyecto.
Responsable del Plan de Revisión de Beneficios (post-proyecto).
Ejecutivo Responsable del Business Case durante toda la vida del proyecto.
Responsable del Plan de Revisión de Beneficios (durante toda la vida del proyecto) a menos
que sea gestionado por la gestión corporativa o del programa.
Controlar el desarrollo de un Business Case viable, asegurando que el proyecto se alinee con
las estrategias corporativas y asegurar la financiación para el proyecto.
Usuario(s) Principal(es) Responsable(s) de especificar los beneficios en base a los cuales se aprueba el Business Case.
Asegurar que se especifique el resultado final del proyecto que se desea lograr.
Asegurar que el proyecto produzca productos que entreguen los resultados finales deseados.
Asegurar que los beneficios esperados (derivados de los resultados finales del proyecto) se
realicen.
Durante las revisiones de beneficios, facilitar un informe de los beneficios reales en
comparación con los previstos.
Proveedor(es) Responsable(s) del o de los Business Case del proveedor (si existen) – véase la sección
Principal(es) 19.6.1.1.
Confirmar que los productos requeridos se pueden entregar dentro de los costes previstos y
que son viables.
Project Manager Preparar el Business Case en nombre del Ejecutivo.
Realizar un análisis de impacto de cualquier cuestión o riesgo nuevo o revisado que afecte la
deseabilidad, viabilidad o capacidad de consecución del proyecto en función de las razones
originales para aprobar el proyecto.
Evaluar y actualizar el Business Case al final de cada fase de gestión.
Evaluar e informar del rendimiento del proyecto al cierre del proyecto.
Garantía del Proyecto Ayudar a desarrollar el Business Case.
(responsabilidades Verificar y hacer el seguimiento del Business Case en función de eventos externos y del
de garantía a nivel progreso del proyecto.
comercial)
Asegurar que el proyecto encaje en el programa o en la estrategia corporativa global.
Seguimiento de las finanzas del proyecto en nombre del cliente.
Asegurar que la solución con una buena relación calidad-precio se revalúe constantemente.
Seguimiento de los cambios en el Plan de Proyecto a fin de identificar cualquier impacto en
las necesidades del negocio o en el Business Case.
Revisar la evaluación del impacto que los cambios posibles podrían tener en el Business Case
y en el Plan de Proyecto.
Verificar y hacer el seguimiento de la alineación del Plan de Revisión de Beneficios con la
gestión corporativa o del programa.
Apoyo al Proyecto El Business Case debe tener una versión baseline y por lo tanto estar bajo la gestión de la
configuración. Apoyo al Proyecto debe informar al Project Manager sobre cualquier cambio
propuesto o real en los productos que afecte el Business Case.
Organización 5
5 Organización
5.1 Propósito
El propósito de la temática de la Organización
es definir y establecer la estructura de
responsabilidades y delegación del proyecto (el
“¿quién?”).
PRINCE2 se basa en un entorno de cliente/proveedor.
Supone que habrá un cliente que especificará el
resultado deseado, y que probablemente pagará
por el proyecto, y un proveedor que suministrará
los recursos y las competencias para entregar ese
resultado.
Cada proyecto necesita dirección, gestión, control y
comunicación efectivos. Establecer al comienzo de
un proyecto una estructura del equipo de gestión
del proyecto y una estrategia de comunicación que
sean efectivas y mantener éstas durante toda la vida
del proyecto son elementos esenciales necesarios
para el éxito de un proyecto.
Uno de los principios de PRINCE2 es que todos
los proyectos deben necesariamente tener una
estructura organizativa definida para unir las
diversas partes bajo las metas comunes del proyecto
y para permitir la toma de decisiones y un gobierno
del proyecto efectivos.
Un equipo de gestión del proyecto exitoso debe:
■■ Contar con representantes comerciales,
del usuario y del proveedor como partes
interesadas
■■ Asegurar gobierno apropiado al definir
responsabilidades para la dirección, gestión y
entrega del proyecto y al definir con claridad
las responsabilidades a cada nivel
■■ Hacer revisiones de los roles del proyecto
durante toda la vida del proyecto para asegurar
que se mantengan efectivos
■■ Contar con una estrategia efectiva para
gestionar el flujo de comunicación a y de las
partes interesadas.
5.2 Organización definida
5.2.1 Proyecto
PRINCE2 define un proyecto como ‘una
organización temporal que ha sido creada con el
propósito de proporcionar uno o más productos
comerciales de acuerdo con un Business Case
convenido’. Necesita ser flexible y es probable
que requiera una amplia gama de competencias
durante un período de tiempo comparativamente
corto.
5.2.2 Programa
Un proyecto se puede realizar como una entidad
independiente o puede ser parte de un programa
de proyectos conectados. Un programa es
una estructura organizativa temporal flexible
creada para coordinar, dirigir y controlar la
implementación de un conjunto de proyectos
y actividades relacionados a fin de entregar
resultados finales y beneficios relacionados con
los objetivos estratégicos de la organización. Es
probable que tenga una vida más larga que un
solo proyecto. Un proyecto que forma parte de un
programa podría verse afectado por la estructura
del programa y las exigencias de rendición de
cuentas.
5.2.3 Organización corporativa
Un proyecto podría o no formar parte de un
programa. Sin embargo, existirá dentro del
contexto más amplio de una organización
corporativa. Las estructuras organizativas
corporativas pueden variar entre estructuras
funcionales ‘tradicionales’ en las cuales el personal
está organizado según el tipo de trabajo (por
ejemplo, marketing, finanzas, ventas, etc., en las
que hay líneas jerárquicas claras) y organizaciones
corporativas centradas en los proyectos, en las que
trabajar con equipos de proyecto es lo normal, con
variaciones intermedias.
36 | Organización
5.2.4 Roles y tareas
A fin de ser flexible y satisfacer las necesidades
de diferentes entornos y proyectos de diferente
tamaño, PRINCE2 no define puestos de
trabajos de gestión a ser asignados al personal
individualmente. Define roles, cada uno de
los cuales se define mediante un conjunto de
responsabilidades asociadas. Los roles se podrán
compartir o combinar, según las necesidades
del proyecto, pero debe asegurarse que las
responsabilidades siempre se asignen. Al combinar
roles, se deben considerar los posibles conflictos
de responsabilidades, si una persona cuenta
con la capacidad necesaria para asumir las
responsabilidades combinadas y si la combinación
crea obstáculos en sí.
5.2.5 Los tres intereses en un proyecto
El principio de PRINCE2 de roles y responsabilidades
definidos afirma que un proyecto PRINCE2 siempre
tendrá tres categorías principales de partes
interesadas y que los intereses de las tres deben
necesariamente ser satisfechos si el proyecto ha de
tener éxito. La Figura 5.1 muestra los tres intereses
principales que componen la Junta de Proyecto.
PRINCE2 recomienda que, para ser completa,
la Junta de Proyecto incluya en todo momento
representación de los intereses: comercial, del
usuario y del proveedor.
■■ Comercial – Los productos del proyecto
deben satisfacer una necesidad comercial
que justificará la inversión en el proyecto.
El proyecto debe también tener una buena
relación calidad-precio. Por lo tanto, el punto
de vista comercial debe estar representado para
asegurar que estos dos prerrequisitos existan
antes de que un proyecto comience y que se
mantengan válidos durante toda la vida del
proyecto. El rol del Ejecutivo se define para
cuidar los intereses comerciales
■■ Usuario – PRINCE2 hace una distinción entre los
intereses comerciales y las exigencias de quienes
utilizarán los resultados del proyecto. El punto
de vista del usuario debe representar a aquellas
personas o grupos a quienes algunos o todos
los puntos siguientes serán de aplicación:
●● Utilizarán los resultados del proyecto para
realizar los beneficios después de que el
proyecto se haya completado
●● Operarán, mantendrán o apoyarán los
resultados del proyecto
●● Los resultados del proyecto tendrán un
impacto en ellos.
La presencia del usuario se necesita para
especificar los resultados deseados y para
asegurar que el proyecto los entregue. El o los
Usuarios Principales representarán el interés de
esta parte interesada en la Junta de Proyecto
■■ Proveedor – La creación de los resultados
del proyecto necesitará recursos con ciertas
competencias. El punto de vista del proveedor
debe representar a aquellos que suministrarán
las competencias necesarias y que producirán
el producto del proyecto. Quizás el proyecto
necesite utilizar equipos de proveedores
tanto internos como externos para construir
el producto del proyecto. El o los Proveedores
Principales representarán el interés de esta
parte interesada en la Junta de Proyecto.
El nivel de coincidencia entre los intereses
comerciales, del usuario y del proveedor cambiará
según el tipo de organización corporativa y de
proyecto. Por ejemplo, si un proyecto utiliza
un proveedor interno, es más probable que los
intereses comerciales y del proveedor coincidan
que si se utiliza un proveedor externo.
Note que el término ‘cliente’ también se utiliza
en PRINCE2, normalmente en un contexto de una
relación comercial de cliente/proveedor. ‘Cliente’
puede, en general, ser interpretado como un
término colectivo para los intereses comerciales
y del usuario. Sin embargo, un ejemplo de una
excepción a esta regla amplia se daría cuando
una organización está desarrollando un producto
nuevo para llevarlo al mercado. En este caso, el
interés comercial se alinea con el del proveedor y
‘cliente’ simplemente se equipara con ‘usuarios’.
Comercial
El
proyecto
Usuario Proveedor
Figura 5.1 Los tres intereses en un proyecto

En los casos en que el interés del usuario es externo
a la organización patrocinadora del desarrollo,
como en este ejemplo, todavía requiere ser
representado de alguna manera – quizás por la
función de ventas/marketing.
Además de las categorías principales de los
intereses comerciales, del usuario y del proveedor
que deben tener representación en la Junta
de Proyecto, habrá una serie más amplia de
partes interesadas que podrían afectar, o verse
afectadas por, el proyecto. Estas partes interesadas
podrían ser internas o externas a la organización
corporativa y podrían apoyar, oponerse o ser
indiferentes al proyecto. La participación efectiva
de estas partes interesadas es un elemento
principal del éxito de un proyecto (véase la
sección 5.3.5).
5.3 El enfoque de la organización
según PRINCE2
5.3.1 Niveles de organización
El nivel de gestión requerido para tomar decisiones
y asumir obligaciones podría estar demasiado
ocupado para participar a diario en el proyecto.
Pero los proyectos necesitan gestión diaria si han de
tener éxito. PRINCE2 separa la dirección y la gestión
del proyecto de la entrega de los resultados del
proyecto, concentrándose en lo primero y utilizando
el principio de gestión por excepción.
La estructura de gestión del proyecto tiene cuatro
niveles, tres de los cuales representan al equipo de
gestión del proyecto y el cuarto que se encuentra
fuera del proyecto. La Figura 5.2 ilustra los niveles
de gestión.
Gestión corporativa o del programa
Equipo de gestión del proyecto
Dirección – Junta de Proyecto
Gestión – Project Manager
Entrega – Team Manager
Figura 5.2 Los cuatro niveles dentro de la
estructura de gestión del proyecto
Organización | 37
Los cuatro niveles de gestión son:
■■ Gestión corporativa o del programa - Este
nivel se ubica fuera del equipo de gestión del
proyecto pero será responsable de encargar
el proyecto, incluyendo la identificación del
Ejecutivo y la definición de las tolerancias a
nivel de proyecto dentro de las cuales la Junta
de Proyecto trabajará. Esta información debe,
de ser posible, ser documentada en el mandato
de proyecto
■■ Dirección - La Junta de Proyecto es responsable
de la dirección y la gestión globales del
proyecto dentro de las restricciones impuestas
por la gestión corporativa o del programa.
La Junta de Proyecto es responsable del éxito
del proyecto. Como parte de la dirección del
proyecto, la Junta de Proyecto:
●● Aprobará todos los planes y recursos
principales
●● Autorizará cualquier desviación que exceda
o que se prevé que excederá las tolerancias
de fase
●● Aprobará la terminación de cada fase y
autorizará el inicio de la fase siguiente
●● Se comunicará con otras partes interesadas
■■ Gestión - El Project Manager es responsable
de la gestión diaria del proyecto dentro de las
restricciones impuestas por la Junta de Proyecto.
La responsabilidad principal del Project
Manager es asegurar que el proyecto produzca
los productos requeridos de conformidad con
las metas de tiempo, coste, calidad, alcance,
riesgo y rendimiento de los beneficios
■■ Entrega - Mientras el Project Manager es
responsable de la gestión diaria del proyecto,
los miembros del equipo son responsables
de la entrega de los productos del proyecto
a un nivel de calidad apropiado dentro
de un calendario y un coste especificados.
Dependiendo del tamaño y la complejidad del
proyecto, la autoridad y la responsabilidad de la
planificación de la creación de ciertos productos
y la gestión de un equipo de especialistas
para que produzcan esos productos se podría
delegar a un Team Manager.
38 | Organización

5.3.2 El equipo de gestión del proyecto Algunas responsabilidades de PRINCE2 no se

5.3.2.1 Estructura del equipo de gestión
del proyecto
Un equipo de gestión del proyecto es una
estructura temporal específicamente diseñada
para gestionar el proyecto hasta su conclusión
exitosa. La estructura tiene en cuenta canales de
comunicación a los foros responsables de toma de
decisiones y se debe respaldar con descripciones
de roles que especifiquen las responsabilidades,
metas, límites de autoridad, relaciones, habilidades,
conocimientos y experiencia que se requieren
para todos los roles en el equipo de gestión del
proyecto. La Figura 5.3 ilustra la estructura del
equipo de gestión del proyecto y sus líneas para
rendición de cuentas.
Los roles del Ejecutivo (en representación del
punto de vista comercial) y del Usuario Principal
(en representación del punto de vista del usuario)
a menudo se pueden combinar. En tales casos,
para evitar cualquier conflicto, se podría nombrar
a dos personas para que realicen la Garantía
del Proyecto, una al cuidado de los intereses del
usuario y la otra en representación de los intereses
comerciales.
pueden compartir ni delegar si se han de realizar
con efectividad. Por ejemplo:
■■ Los roles de Project Manager y de Ejecutivo no
se pueden compartir. El Ejecutivo no puede ser
asimismo el Project Manager y no puede haber
más de un Ejecutivo o Project Manager
■■ La responsabilidad de tomar decisiones del
Project Manager y de la Junta de Proyecto no se
puede delegar.
PRINCE2 facilita resúmenes de las descripciones de
roles que se encontrarán en el Apéndice C. Éstas
deben ser adaptadas a las necesidades del proyecto
específico y a cada nombramiento específico.
5.3.2.2 Junta de Proyecto
El Ejecutivo, el o los Usuarios Principales y
el o los Proveedores Principales constituyen,
conjuntamente, la Junta de Proyecto. La Junta de
Proyecto tiene autoridad sobre el proyecto y es
responsable de éste de acuerdo a las instrucciones
(inicialmente contenidas en el mandato de
proyecto) estipuladas por la gestión corporativa o
del programa.
PRINCE2 define las responsabilidades de la Junta de
Proyecto de la siguiente manera:

Gestión corporativa o del programa

Junta de Proyecto
Usuario(s) Proveedor(es)
Ejecutivo
Principal(es) Principal(es)

Garantía del Proyecto Autoridad

a nivel comercial, de de Cambios
usuario y de proveedor
Project Manager

Apoyo al Proyecto

Team Manager(s)

Miembros del equipo

Dentro del equipo de gestión del proyecto Líneas jerárquicas

Del cliente Responsabilidad de Garantía del Proyecto

Del proveedor Líneas de apoyo/asesoramiento

Figura 5.3 Estructura del equipo de gestión del proyecto


■■ Ser responsable, y rendir cuentas a la gestión
corporativa o del programa, del éxito o fracaso
del proyecto en términos de los intereses
comerciales, del usuario y del proveedor
■■ Proporcionar dirección unificada al proyecto.
Debido a que una de las responsabilidades
principales de la Junta de Proyecto es
proporcionar dirección al Project Manager, es
importante que todos los miembros tengan una
opinión unificada de lo que la dirección debe
ser
■■ Delegar con efectividad, utilizando la estructura
organizativa de PRINCE2 y los controles
diseñados para este propósito
■■ Facilitar la integración del equipo de gestión
del proyecto con las unidades funcionales de
las organizaciones corporativas o externas que
participan
■■ Proveer los recursos y autorizar los fondos
necesarios para permitir que el proyecto se
termine con éxito
■■ Asegurar una toma de decisiones efectiva
■■ Proporcionar apoyo visible y sostenido al Project
Manager
■■ Asegurar la comunicación efectiva tanto dentro
del equipo del proyecto como con las partes
interesadas externas.
En Directing Successful Projects with PRINCE2 (TSO,
2009) de OGC se podrá encontrar más orientación
sobre estas responsabilidades.
Una Junta de Proyecto buena debe contar con
cuatro características principales:
■■ Autoridad - Los miembros de la Junta de
Proyecto deben ocupar cargos de suficiente
responsabilidad en la organización corporativa
como para tomar decisiones estratégicas sobre
el proyecto. Debido a que la Junta de Proyecto
es responsable del proyecto, las personas
elegidas deben tener autoridad suficiente para
tomar estas decisiones y para facilitar recursos
para el proyecto, tales como personal, dinero
en efectivo y equipamiento. El nivel de gestión
requerido para llenar estos roles dependerá de
factores tales como el presupuesto, el alcance y
la importancia del proyecto
■■ Credibilidad - La credibilidad de los miembros
de la Junta de Proyecto dentro de la
organización corporativa afectará su habilidad
para dirigir el proyecto
Organización | 39
■■ Habilidad para delegar - Una parte principal
del rol de la Junta de Proyecto consiste en
asegurar que se dé al Project Manager ‘espacio’
suficiente para gestionar el proyecto al
mantener la actividad de la Junta de Proyecto
al nivel correcto. Los miembros de la Junta de
Proyecto no deben participar en los detalles de
la manera en que el proyecto se gestiona, ni en
el contenido especializado del proyecto
■■ Disponibilidad - Los miembros de la Junta de
Proyecto que reúnan todas las características
anteriores son de poco valor para el proyecto
si no están disponibles para tomar decisiones y
proporcionar dirección al Project Manager.
Los miembros de la Junta de Proyecto a menudo
provienen de cargos a nivel de personal directivo
superior y sus responsabilidades como miembros
de la Junta de Proyecto serán adicionales a sus
responsabilidades normales. El concepto de
gestión por excepción permite al Project Manager
mantenerles informados con regularidad sobre el
progreso del proyecto pero sólo requiere toma de
decisiones en los puntos principales del proyecto.
La frecuencia y los detalles de la comunicación
requeridos por la Junta de Proyecto durante un
proyecto se deben documentar en la Estrategia de
Gestión de la Comunicación. Los miembros de la
Junta de Proyecto podrían requerir información
más detallada o frecuente al iniciarse el proyecto.
A medida que el proyecto progresa y que el nivel
de confianza de la Junta de Proyecto aumenta en
el progreso que se está logrando, la exigencia de
Informes de Desarrollo frecuentes y detallados se
podría reducir. Es importante revisar el nivel y la
frecuencia de presentación de informes para cada
fase durante el proceso de la Gestión de los Límites
de Fase.
Ejecutivo
Aunque la Junta de Proyecto es responsable del
proyecto, el Ejecutivo (con el apoyo del o de los
Usuarios Principales y del o de los Proveedores
Principales) es en última instancia el responsable
del éxito del proyecto y es el principal encargado
de tomar decisiones. La Junta de Proyecto no es
una democracia controlada por votos.
El rol de Ejecutivo consiste en asegurar que el
proyecto se centre durante toda su vida en el logro
de sus objetivos y en la entrega de un producto
que logrará los beneficios previstos. El Ejecutivo
debe asegurar que el proyecto tenga una buena
40 | Organización
relación calidad-precio, asegurando un enfoque
orientado al control de costes para el proyecto,
equilibrando las demandas comerciales, del usuario
y del proveedor.
La gestión corporativa o del programa nombra
al Ejecutivo durante el proceso de la Puesta en
Marcha de un Proyecto, que tiene lugar antes del
inicio del proyecto. El rol de Ejecutivo se confiere
a una persona física de modo que haya un punto
de responsabilidad para el proyecto en última
instancia. El Ejecutivo será por lo tanto responsable
de diseñar y de nombrar al resto del equipo
de gestión del proyecto, incluyendo los otros
miembros de la Junta de Proyecto. Si el proyecto es
parte de un programa, la gestión corporativa o del
programa podría nombrar a algunos o a todos los
miembros de la Junta de Proyecto.
Durante toda la vida del proyecto, el Ejecutivo es
responsable del Business Case.
Usuario Principal
El o los Usuarios Principales son responsables de
especificar las necesidades de quienes utilizarán los
productos del proyecto, de actuar de enlace entre
el usuario y el equipo de gestión del proyecto y de
hacer el seguimiento de que la solución satisfaga
esas necesidades dentro de las restricciones del
Business Case en términos de calidad, funcionalidad
y facilidad de uso.
El rol representa los intereses de todos aquellos
que utilizarán los productos del proyecto
(incluyendo operaciones y mantenimiento), de
aquellos para quienes los productos lograrán un
objetivo, o de aquellos que utilizarán los productos
para entregar beneficios. El rol de Usuario Principal
asigna recursos del usuario y hace el seguimiento
de los productos en función de las exigencias.
Este rol podría requerir más de una persona para
cubrir todos los intereses del usuario. Por razones
de efectividad, el rol no se debe dividir entre
demasiada gente.
El o los Usuarios Principales especifican los
beneficios y son responsables de demostrar a
la gestión corporativa o del programa que los
beneficios previstos que formaron la base para
la aprobación del proyecto se han, de hecho,
realizado. Es probable que esto implique un
compromiso más allá del final de la vida del
proyecto.
Proveedor Principal
El o los Proveedores Principales representan los
intereses de quienes diseñan, desarrollan, facilitan,
obtienen e implementan los productos del
proyecto.
Este rol es responsable de la calidad de los
productos entregados por el o los proveedores, así
como de la integridad técnica del proyecto. Este rol
incluirá proporcionar los recursos del proveedor al
proyecto y asegurar que las propuestas de diseño
y desarrollo de los productos sean factibles y
realistas.
En la mayoría de los casos, el Proveedor Principal
también representa los intereses de aquellos que
mantendrán los productos especializados del
proyecto después de su cierre, por ej., apoyo y
mantenimiento de ingeniería. Ocurren excepciones
a lo anterior, por ej., cuando un proveedor externo
entrega productos a un cliente que los mantendrá
en servicio/funcionamiento. En este caso es más
probable que los intereses de operaciones y
mantenimiento estén representados por un Usuario
Principal. De hecho, la distinción no es realmente
importante; lo que importa es que los intereses de
operaciones, servicio y apoyo estén debidamente
representados desde el principio.
De ser necesario, se podría requerir más de una
persona para representar a los proveedores.
5.3.2.3 Garantía del Proyecto
La Junta de Proyecto es responsable, a través
de su rol de Garantía del Proyecto, de hacer
el seguimiento de todos los aspectos del
rendimiento del proyecto y de los productos,
independientemente del Project Manager.
Los miembros de la Junta de Proyecto son
responsables de los aspectos de Garantía del
Proyecto que están alineados con las respectivas
áreas que les atañen – comercial, usuario o
proveedor. Si disponen de tiempo suficiente y del
nivel apropiado de habilidades y conocimientos,
pueden llevar a cabo sus propias tareas de Garantía
del Proyecto; de lo contrario, pueden nombrar a
otras personas para su realización.
La Junta de Proyecto también puede hacer uso
de otros miembros de la organización corporativa
para que asuman roles de Garantía del Proyecto
específicos, tales como el nombramiento del
gerente de calidad corporativo para que realice

el seguimiento de los aspectos de calidad del
proyecto. Los miembros de la Junta de Proyecto
son responsables de las acciones de Garantía del
Proyecto alineadas con su área de interés, aun
cuando deleguen éstas a otras personas.
Garantía del Proyecto no es, sin embargo, tan sólo
una comprobación independiente. El personal
que participa en Garantía del Proyecto también
es responsable de apoyar al Project Manager
al proporcionarle asesoramiento y orientación
sobre cuestiones tales como el uso de las normas
corporativas o el personal correcto que ha de
participar en diferentes aspectos del proyecto, por
ej., inspecciones o revisiones de calidad.
En los casos en que los miembros de la Junta de
Proyecto y otras personas compartan las tareas de
Garantía del Proyecto, es importante aclarar las
responsabilidades de cada persona. Cualquiera que
sea nombrado a un rol de Garantía del Proyecto
rinde cuentas al miembro de la Junta de Proyecto
que controla el área de interés pertinente y debe
ser independiente del Project Manager. La Junta de
Proyecto no debe asignar ningún rol de Garantía
del Proyecto al Project Manager.
Como parte de su función de hacer el seguimiento
de todos los aspectos del rendimiento del proyecto
y los productos independientemente del Project
Manager, Garantía del Proyecto debe participar en
todos los procesos de PRINCE2.
5.3.2.4 Autoridad de Cambios
Una consideración que se debe tener en cuenta
al iniciarse el proyecto es a quién se le permitirá
autorizar solicitudes de cambio o los fuera de
especificación. La Junta de Proyecto es responsable
de aceptar cada cambio posible antes de su
implementación. En un proyecto en el que se
prevén pocos cambios, sería razonable dejar esta
autoridad en manos de la Junta de Proyecto.
Pero los proyectos podrían estar en un entorno
dinámico en los cuales es probable que haya, por
ejemplo, muchas solicitudes de cambio del alcance
inicialmente acordado para el proyecto. También
se podrían necesitar conocimientos técnicos para
evaluar los cambios potenciales.
Antes de que el proyecto salga de la fase de inicio,
la Junta de Proyecto necesita decidir si desea
delegar cierta autoridad para aprobar o rechazar
solicitudes de cambio o los fuera de especificación.
Organización | 41
Para facilitar esto, la Junta de Proyecto debe definir
en la Estrategia de Gestión de la Configuración
una escala de clasificaciones de severidad para
las solicitudes de cambio. Dependiendo de la
severidad, la solicitud de cambio podría ser
manejada por:
■■ la gestión corporativa o del programa
■■ la Junta de Proyecto
■■ delegación a una Autoridad de Cambios
■■ delegación al Project Manager.
Estas autoridades delegadas se deben incluir en las
descripciones de roles apropiadas. Para proyectos
que existen dentro de un programa, la gestión del
programa debe definir el nivel de autoridad que
la Junta de Proyecto tendrá a fin de poder aprobar
cambios.
El Project Manager y/o las personas a quien se le
han delegado responsabilidades de Garantía del
Proyecto podrán actuar como la Autoridad de
Cambios. Para más información sobre cambios,
véase el Capítulo 9.
Ejemplo de una Autoridad de Cambios
Se da a un Project Manager autoridad para
aprobar cambios a productos individuales sólo si
los cambios:
■■ Cuestan menos de un límite previamente
acordado
■■ No tienen un impacto en los calendarios del
proyecto superior a una semana
■■ No requieren ningún cambio a la Descripción
del Producto del Proyecto o a cualquier otro
producto.
Para cualquier cambio fuera de estos límites se
debería presentar una excepción a la Junta de
Proyecto.
5.3.2.5 Tamaño de la Junta de Proyecto
El Ejecutivo, apoyado por el Project Manager, es
responsable de convenir una estructura de equipo
apropiada y de adaptarla al tamaño, nivel de riesgo
y complejidad del proyecto. La Junta de Proyecto
necesita representar a todas las partes interesadas
en la organización corporativa y hacer participar
a cualquier proveedor (interno o externo) que se
haya identificado.
42 | Organización

En un proyecto grande, adaptar el equipo de
gestión del proyecto podría significar dividir los
roles de PRINCE2 en múltiples nombramientos
– por ejemplo, se podrían nombrar varios
Usuarios Principales o Proveedores Principales.
Sin embargo, es una buena práctica mantener la
Junta de Proyecto tan reducida como sea posible
mientras todavía se representen todos los intereses
comerciales, de usuarios y de proveedores. Para
evitar agrandar la Junta de Proyecto, se podrían
utilizar grupos de usuarios o proveedores para
mantener un amplio alcance de participación del
personal directivo superior en aquellos proyectos
que tienen un impacto en una comunidad de
usuarios o proveedores grande. Estos grupos
discuten cuestiones y riesgos que afectan a usuarios
o proveedores y pasan recomendaciones al o a
los Usuarios Principales o al o a los Proveedores
Principales en la Junta de Proyecto. Si participa un
grupo de usuarios o proveedores, es importante
definir al principio quién está autorizado para
representar su opinión colectiva y la manera en
que esto funcionará. Quizás también sea apropiado
nombrar miembros de estos grupos a Garantía del
Proyecto a nivel de usuario o proveedor; múltiples
personas pueden desempeñar roles de Garantía del
Gestión corporativa o del programa
Proyecto. El contexto comercial también afectará la
estructura organizativa del proyecto (por ej., si se
nombra a un contratista principal).
Usuario(s)
Grupos de Principal(es)
usuarios
Usuario Principal
La Figura 5.4 muestra una posible estructura
organizativa a nivel de proyecto que incluye
grupos de usuarios y de proveedores.
Producir una matriz de las partes interesadas en
función de los productos del proyecto también
ayuda a separar las partes interesadas del
proyecto (que se deben involucrar como parte de
la Estrategia de Gestión de la Comunicación) de
quienes toman las decisiones para el proyecto (que
necesitan estar en la Junta de Proyecto).
La decisión de si se incluyen proveedores externos
en la Junta de Proyecto podría ser una decisión
cultural basada en el temor a que se divulgue
información comercial o financiera. Dejarlos fuera
del proceso de la Dirección de un Proyecto podría
causar demoras debido a la falta de recursos de
proveedor para hacer frente a cambios y para
abordar cuestiones especializadas. Es el Ejecutivo
quien, en la práctica, debe decidir cómo resolver
este dilema.
Junta de Proyecto
Proveedor(es)
Ejecutivo
Junta de Proyecto Principal(es) Grupos de
proveedores
Ejecutivo Proveedor Principal

Garantía del Proyecto Autoridad

a nivel comercial, de de Cambios
Representante usuario y de proveedor Representante
del usuario Project Manager del proveedor
(área 1) (área 1)
Representante Representante
Apoyo al Proyecto
del usuario del proveedor
(área 2) Garantía del Proyecto Garantía del Proyecto Garantía del Proyecto (área 2)
a nivel de usuario a nivelManager(s)
Team comercial a nivel de proveedor

Miembros del equipo

Dentro del equipo de gestión del proyecto Líneas jerárquicas

Del cliente
Dentro del equipo de gestión del proyecto Responsabilidad de Garantía del Proyecto

Del proveedor
Del cliente Líneas de apoyo/asesoramiento

Del proveedor
Figura 5.4 Posible estructura organizativa utilizando grupos de usuarios y de proveedores
Líneas jerárquicas

Responsabilidad de Garantía del Proyecto

Líneas de apoyo/asesoramiento

5.3.2.6 Project Manager
El Project Manager es el único responsable central
de la gestión diaria de un proyecto. Esta persona
tiene la autoridad para dirigir el proyecto en
nombre de la Junta de Proyecto dentro de las
restricciones estipuladas por la Junta de Proyecto.
En un entorno de PRINCE2, el rol del Project
Manager no se debe compartir.
Normalmente, el Project Manager procede de la
organización corporativa del cliente, pero podría
haber proyectos en los cuales el Project Manager
proceda del proveedor. Para más información sobre
las relaciones cliente/proveedor, véase el
Capítulo 19.
El Project Manager es responsable del trabajo de
todos los procesos de PRINCE2, salvo el proceso
de la Dirección de un Proyecto y de nombrar al
Ejecutivo y al Project Manager en el proceso de la
Puesta en Marcha de un Proyecto antes del inicio
de un proyecto. El Project Manager también delega
responsabilidades del proceso de la Gestión de la
Entrega de Productos al o a los Team Managers.
El Project Manager dirige a los Team Managers y
al Apoyo al Proyecto y es responsable de actuar
de enlace con Garantía del Proyecto y la Junta
de Proyecto. En proyectos en los cuales no se
ha asignado a una persona distinta para un
rol de Team Manager, el Project Manager será
responsable de gestionar el trabajo directamente
con los miembros del equipo en cuestión. En
los proyectos sin un rol de Apoyo al Proyecto
separado, las tareas de apoyo también recaerán
sobre el Project Manager, si bien se podrán
compartir con los miembros del equipo.
En calidad de único responsable central de la
gestión diaria de un proyecto, hay muchos aspectos
diferentes del rol de Project Manager. La Figura 5.5
muestra algunas de estas facetas diferentes.
Gestión jerárquica
Estrategia Gestión de coste
Trabajo en equipo Comunicación
Project
Planificación Calidad
Manager
Estado del producto
Seguimiento
Necesidades del usuario Necesidades del producto vs.
Cambios necesidades del proyecto
Figura 5.5 Las diversas facetas del rol de Project
Manager
Organización | 43
5.3.2.7 Team Manager
La principal responsabilidad del Team Manager es
asegurar la producción de los productos asignados
por el Project Manager. El Team Manager recibe
instrucciones del Project Manager y le rinde
cuentas.
El rol de Team Manager se podrá asignar al
Project Manager o a otra persona. Hay muchas
razones por las cuales el Project Manager podría
decidir nombrar a otras personas para que sean
Team Managers más bien que desempeñar el rol
él mismo. Entre éstas cabe destacar el tamaño
del proyecto, las habilidades o los conocimientos
especializados particulares necesarios para
ciertos productos, la ubicación geográfica de
ciertos miembros del equipo y las preferencias
de la Junta de Proyecto. El Project Manager debe
discutir la necesidad de que diferentes personas se
desempeñen como Team Managers con la Junta
de Proyecto y, si se requiere, debe planificar el rol
al comienzo del proyecto, durante el proceso de la
Puesta en Marcha de un Proyecto, o para cada fase
en el proceso de la Gestión de los Límites de Fase.
PRINCE2 utiliza Paquetes de Trabajo para asignar
trabajo a los Team Managers o a los miembros
de los equipos. Se pueden utilizar formal o
informalmente, dependiendo de las necesidades
del proyecto. Además de la información incluida en
el Apéndice A, un Paquete de Trabajo puede incluir
elementos tales como coste de los recursos, códigos
contables, recursos asignados y otra información
de gestión. Definir los productos a entregar al
nivel apropiado también ayudará a los Team
Managers nuevos a ser más eficaces, ya que lo que
se debe producir está claro y con la definición de
la frecuencia y del método para la presentación
de informes, las respuestas del Team Manager se
pueden controlar con claridad.
Si el Team Manager proviene de la organización
corporativa del proveedor, podría haber una línea
para rendición de cuentas a un Proveedor Principal.
Es fundamental que se comprenda cualquiera de
estos enlaces a fin de evitar que haya conflictos
de interés y que se socave la autoridad del Project
Manager.
La estructura del equipo de gestión del proyecto
no refleja necesariamente funciones de línea ni
jerarquías sino que representa roles en el proyecto.
Por ejemplo, un Team Manager podría tener más
jerarquía en la organización corporativa que el
44 | Organización
Project Manager, o podría ser un representante
principal de un proveedor externo. En el contexto
del proyecto, sin embargo, el Team Manager rinde
cuentas y recibe instrucciones del Project Manager.
5.3.2.8 Apoyo al Proyecto
El Project Manager es responsable de Apoyo
al Proyecto. Si se requiere, el Project Manager
puede delegar parte de este trabajo a un
rol de Apoyo al Proyecto: esto podría incluir
prestar servicios administrativos o proporcionar
asesoramiento y orientación sobre el uso de las
herramientas de gestión del proyecto o la gestión
de la configuración. También podría cumplir
funciones especializadas para un proyecto, tales
como planificación o gestión del riesgo. A menos
que sea realizado por una función de gestión
corporativa o del programa, Apoyo al Proyecto por
lo general es responsable de administrar cualquier
procedimiento y herramienta de gestión de la
configuración, según lo definido en la Estrategia
de Gestión de la Configuración.
Es importante recalcar que el rol de Apoyo al
Proyecto no es opcional, pero la asignación de
otra persona o grupo para realizar las tareas
requeridas sí lo es. Apoyo al Proyecto recae sobre el
Project Manager por defecto si no se asigna a otra
persona.
Algunas organizaciones corporativas podrían tener
una oficina de proyecto (una oficina temporal
establecida para apoyar la entrega de un proyecto
específico) o una estructura similar que puede
desempeñar la totalidad o parte del rol de Apoyo
al Proyecto. Para más información sobre el uso
de una oficina de proyecto, véase la publicación
Portfolio, Programme and Project Offices (P3O®)
de OGC.
Los roles de Apoyo al Proyecto y de Garantía
del Proyecto se deben mantener separados a fin
de mantener la independencia de Garantía del
Proyecto.
5.3.2.9 Cómo tratar los cambios en el
equipo de gestión del proyecto
Lo ideal sería que el Project Manager y los
miembros de la Junta de Proyecto continúen
participando en el proyecto durante toda la vida
de éste. En la práctica, sin embargo, esto podría
no siempre ser posible y el equipo de gestión del
proyecto podría cambiar durante el proyecto. Una
estructura de equipo claramente definida, junto
con descripciones de roles globales que resuman
las responsabilidades de cada rol, deberían ayudar
a aliviar los trastornos causados por cambios en el
equipo de gestión del proyecto.
El uso de fases de gestión también permite una
transición uniforme para cambios en el equipo
de gestión del proyecto. Es durante el proceso de
la Gestión de los Límites de Fase que los roles del
proyecto se deben revisar para la fase siguiente.
El uso de Informes al Final de Fase y de Planes
de Fase puede ayudar a asegurar que cualquier
procedimiento de entrega sea meticuloso y
esté bien documentado. Si bien lo ideal es que
el Ejecutivo del Proyecto y el Project Manager
continúen con el proyecto durante todo su
ciclo de vida, un límite de fase proporciona una
oportunidad para realizar el cambio de personas en
el rol durante el proyecto si esto fuera necesario.
Ejemplo de cambio en el equipo de gestión del
proyecto
Un proyecto podría incluir una fase de
adquisición durante la cual se selecciona un
proveedor para que desarrolle algunos de
los productos del proyecto. Antes de que se
seleccione al proveedor, un representante
principal del departamento de compras podría
representar al Proveedor Principal en el
proyecto. Después de que se haya seleccionado
al proveedor y el proyecto pase a la fase de
desarrollo, se podría incluir a un representante
principal de la organización del proveedor
seleccionado en el equipo en calidad de
Proveedor Principal.
5.3.3 Trabajar con el equipo del
proyecto
5.3.3.1 Equilibrio entre proyecto, equipo y
personas
Las personas son un elemento fundamental para
el éxito de un proyecto. No es suficiente tener
implementados los procesos y sistemas requeridos:
si las personas que participan en un proyecto
no trabajan juntas con efectividad, se limitan
seriamente las posibilidades de éxito del proyecto.
Conocer los diferentes tipos de personalidades y
la manera en que trabajan juntos puede ayudar al
Project Manager a estructurar equipos equilibrados

que pueden trabajar juntos con efectividad
durante un proyecto.
Diferentes personas tienen diferentes
características y ciertos tipos de individuos se
prestan mejor para ciertos roles. En un entorno
dado, algunas combinaciones de tipos de
personalidades funcionan mejor que otras.
Ejemplo de creación de equipos utilizando
diferentes personalidades
Algunas personas son muy sociables y
entusiastas y generan muchas ideas diferentes.
Otras son más analíticas, hábiles para trabajo
detallado y para asegurar que no se pase por
alto ninguna tarea. Aunque normalmente no
sea posible cambiar las características de las
personas, es posible equilibrar un equipo de
modo tal que tenga una mezcla de tipos de
personalidades apropiada para permitir que las
tareas se completen con efectividad. Los Project
Managers pueden utilizar los conocimientos
sobre las características de las personalidades
para crear equipos efectivos tanto durante el
proceso de la Puesta en Marcha de un Proyecto,
para el equipo de gestión, como durante el
proceso del Inicio de un Proyecto cuando identi-
fiquen a los miembros de los varios equipos.
Es importante lograr el equilibrio correcto:
por ejemplo, un equipo que sólo cuenta con
personas con ‘ideas’ corre el riesgo de perder
de vista el concentrarse en los detalles de las
tareas que es necesario realizar. A la inversa,
un equipo compuesto solamente por personas
‘centradas en los detalles’ podría no tener una
visión general estratégica de una solución.
5.3.3.2 Necesidades de capacitación para
los equipos del proyecto
Al iniciarse el proyecto, los miembros de los
equipos podrían necesitar capacitación. Esto podría
incluir capacitación en cualquier proceso y norma
a ser utilizados en el proyecto (tales como los
procedimientos de gestión de la configuración,
métodos de calidad, informes de progreso y otras
áreas específicas al proyecto), o podría ser una
introducción al proyecto y a sus metas diseñada
para motivar a los miembros del equipo. Los
miembros de la Junta de Proyecto también podrían
necesitar capacitación sobre sus roles, incluyendo
qué se espera de ellos y los procedimientos
Organización | 45
necesarios para cumplir sus responsabilidades. Los
Team Managers y otros miembros del equipo de
gestión del proyecto también podrían requerir
capacitación en los procesos y la terminología de
PRINCE2.
Durante un proyecto, los miembros de los
equipos también podrían necesitar capacitación
especializada para permitirles completar las tareas
que les han sido asignadas. El Project Manager
debe asegurar que las necesidades de capacitación
se incorporen a los planes apropiados.
5.3.3.3 Equipos a tiempo parcial
Los equipos de un proyecto se reúnen para toda
la duración de un proyecto y luego regresan a su
trabajo habitual. Es probable, por lo tanto, que el
gerente de un proyecto pequeño encuentre que
los miembros de los equipos están trabajando a
tiempo parcial en el proyecto. Los miembros de
equipos que participan a tiempo parcial sufren
más ausencias y distracciones, como porcentaje de
sus horas de trabajo, que los miembros de equipos
con dedicación exclusiva. El Project Manager debe
tener esto en cuenta al diseñar un plan – ya sea
negociando disponibilidad garantizada o mayor
tolerancia.
Si se encarga al personal que trabaje en
demasiados proyectos, simplemente quedarán
estancados en todos los proyectos, dedicando
mucho esfuerzo pero no logrando ningún
progreso. Las soluciones incluyen realizar menos
proyectos en paralelo o, cuando sea posible,
asignar personal con dedicación exclusiva a
proyectos durante períodos limitados.
5.3.4 Trabajar con la organización
corporativa
5.3.4.1 Gestión de línea/gestión funcional
En un entorno fuertemente funcional, los Project
Managers pueden tener dificultades al gestionar
proyectos interfuncionales debido a la incapacidad
para acordar una dirección general desde dentro
de los diversos grupos. Como resultado, podría
ser necesario que la Junta de Proyecto participe
más estrechamente para guiar, dirigir y priorizar
el trabajo y resolver cuestiones. Cualquiera sea el
entorno, el Project Manager deberá adaptarse y
trabajar dentro de la organización corporativa y
esto afectará el nivel de gestión requerido para los
miembros del equipo.
46 | Organización

Un centro de excelencia puede ser útil en los casos

Ejemplo de las responsabilidades de un Project
en que:
Manager para con la gestión de línea/funcional
■■ La falta de recursos, ya sea en su número o en
El Project Manager podría ser responsable de
competencias, haga que sea difícil proporcionar
realizar las valoraciones de rendimiento como
personas para realizar las tareas de
parte de un proyecto, o podría hacer aportes
administración del proyecto para cada proyecto
a la valoración realizada por el área funcional
corriente
de la organización corporativa responsable del
■■ Haya una serie de proyectos pequeños de
miembro del equipo.
naturaleza diversa que individualmente
requieren sólo apoyo limitado de Apoyo al
Comprender la organización corporativa más
Proyecto
amplia y trabajar dentro de ésta puede ser un
■■ Haya un programa de envergadura que
desafío para el Project Manager, especialmente si
requiere coordinación de proyectos individuales
trabaja a tiempo parcial o en virtud de un contrato.
■■ Un proyecto grande requiera varios recursos
Fijar controles claros para el proyecto al iniciarse
éste y acordarlos con la Junta de Proyecto ayudará para manejar los roles de Apoyo al Proyecto.
a asegurar que el Project Manager comprenda el Para más información sobre el centro de excelencia
nivel de interacción y apoyo que puede esperar y su relación con los proyectos, véase la publicación
durante el proyecto y que se le dé exposición Portfolio, Programme and Project Offices (TSO,
apropiada a otras áreas de la organización 2008) de OGC.
corporativa.
5.3.5 Trabajar con las partes interesadas
5.3.4.2 Centro de excelencia
El concepto de un centro de excelencia es aquél 5.3.5.1 Tipos de partes interesadas
de una unidad central facilitadora de normas Es probable que haya personas o grupos que no
que define las normas (tales como los procesos, son parte del equipo de gestión del proyecto pero
las plantillas y herramientas) y proporciona las que podrían necesitar interactuar con el proyecto o
competencias, la capacitación y posiblemente que se podrían ver afectadas por el resultado final
funciones de garantía independientes a una serie del proyecto. Estas personas podrían:
de proyectos. ■■ Apoyar u oponerse al proyecto
■■ Ganar o perder como resultado de la entrega
Ejemplo de un centro de excelencia
del proyecto
Una organización ha establecido un centro de ■■ Considerar que el proyecto es una amenaza u
excelencia que facilita: optimiza su posición
■■ Un sistema de archivo central para todos los ■■ Pasar a apoyar o bloquear activamente el
proyectos proyecto y su progreso.
■■ Un sistema de gestión de la configuración Es importante analizar quiénes son estas partes
■■ Pericia para estimar técnicas interesadas y hacer que se impliquen debidamente.
■■ Asesoramiento sobre la preparación de
planes
■■ Una base de datos histórica del tiempo
que llevan ciertas actividades específicas
(métrica) y un análisis de productividad
■■ Pericia y asesoramiento sobre PRINCE2
■■ Informes consolidados que resumen el
estado de todos los proyectos en la cartera.

Ejemplo de análisis de las partes interesadas
El análisis de las partes interesadas identificó las
siguientes partes interesadas para un proyecto
para el traslado de una fábrica de sustancias
químicas:
■■ Una serie de sindicatos
■■ Un grupo de presión ambiental
■■ Un regulador de la industria
■■ La función de garantía de calidad del
programa
■■ Una serie de funciones de gestión
corporativa (por ejemplo, auditoría interna,
finanzas, sección legal)
■■ El contratista externo
■■ Algunas personas afectadas por el proyecto.
Nótese que algunos de éstos eran externos al
equipo de gestión del proyecto pero internos
a la organización de gestión corporativa o del
programa.
5.3.5.2 Participación de las partes
interesadas
La participación de las partes interesadas es
el proceso de identificar y comunicarse con
efectividad con aquellas personas o grupos que
tienen un interés o influencia en el resultado final
del proyecto. Generalmente se realiza a nivel de
programa. Todos los proyectos necesitan tener
un cierto nivel de participación de ciertas partes
interesadas, especialmente si no son parte de un
programa.
Las partes externas al equipo de gestión del
proyecto pueden tener gran influencia en un
proyecto. La comunicación efectiva con las
principales partes interesadas, tanto internas como
externas a la organización corporativa, es esencial
al éxito del proyecto.
Organización | 47
Ejemplo de participación de las partes
interesadas
La publicación Managing Successful
Programmes (MSP™) de OGC identifica
un procedimiento de seis pasos para hacer
participar a las partes interesadas:
■■ Identificación de las partes interesadas
(¿Quién?) - Identificar a las partes
interesadas individuales involucradas en
el proyecto o afectadas por éste y quizás
agrupar a partes interesadas similares
de modo que los mensajes principales se
puedan dirigir a ellas con efectividad
■■ Creación y análisis de perfiles de las
partes interesadas (¿Qué?) -Comprender
las influencias, intereses y actitudes de
las partes interesadas hacia el proyecto y
la importancia y el poder de cada parte
interesada. Por ejemplo, ¿es probable
que un grupo determinado sea negativo,
cualquiera sea el mensaje, y que por lo tanto
requiera atención especial? La influencia y
todos los intereses de las partes interesadas,
sean éstos racionales o emocionales, se
deben necesariamente tener en cuenta.
Tienen el potencial para afectar el éxito
del proyecto. Las percepciones podrían ser
erróneas, pero debe asegurarse de que se
aborden. La percepción de beneficios por
parte de las partes interesadas se debe
cuantificar cuando sea posible
■■ Definición de la estrategia para la
participación de las partes interesadas
(¿Cómo?) - Definir la manera en que
el proyecto puede hacer que las partes
interesadas se comprometan con
efectividad, incluyendo la definición de
las responsabilidades de comunicación y
los principales mensajes que es necesario
transmitir. Para cada parte interesada, se
convendrá:
●● La información que la parte necesita del
proyecto
●● El método, formato y la frecuencia de la
comunicación
●● El remitente y el receptor de la
comunicación
48 | Organización
■■ Planificación del compromiso (¿Cuándo?)
- Definir los métodos y la oportunidad de
las comunicaciones. Éstos se planifican de
la mejor manera posible después de definir
la forma en que el proyecto solicitará
la participación de las diferentes partes
interesadas. Al seleccionar los remitentes
de información, es importante seleccionar
a comunicadores respetados por el público.
Su posición en la organización corporativa
y su pericia en el tema influirán en gran
medida en su credibilidad. Para muchos
proyectos se realiza una reunión inicial
formal para presentar el proyecto y sus
metas a la organización corporativa. Si se
utiliza este tipo de reunión, es importante
que los miembros de la Junta de Proyecto
estén presentes para mostrar su apoyo y
compromiso al proyecto
■■ Compromiso de las partes interesadas
(Hacer) - Concretar la participación y las
comunicaciones planificadas. Los dos
primeros pasos en lograr la participación
de las partes interesadas – identificación y
análisis – también logran la participación de
las partes interesadas hasta un cierto punto
■■ Medición de la efectividad (Resultados) -
Comprobar la efectividad de la participación.
Garantía del Proyecto podría participar en
la consulta con todas las partes interesadas
principales, así como en la verificación de
sus necesidades de información y de que
se cubran los canales de comunicación
apropiados.
5.3.5.3 La Estrategia de Gestión de la
Comunicación
La Estrategia de Gestión de la Comunicación
contiene una descripción de los medios y de la
frecuencia de la comunicación a las partes tanto
internas como externas del proyecto. Facilita la
participación de las partes interesadas mediante
el establecimiento de un flujo de información
controlado y bidireccional. Cuando el proyecto es
parte de un programa, la Estrategia de Gestión
de la Comunicación también debe definir la
información que el programa necesita y la manera
en que ésta se ha de comunicar.
Si se ha completado un procedimiento formal de
participación de las partes interesadas, tal como
el que se describe anteriormente, éste también se
debe documentar como parte de la Estrategia de
Gestión de la Comunicación. Véase al Apéndice A
para más información sobre el contenido sugerido
para la Estrategia de Gestión de la Comunicación.
El Project Manager es responsable de documentar
la Estrategia de Gestión de la Comunicación
durante el proceso del Inicio de un Proyecto.
También es importante revisar, y posiblemente
actualizar, la Estrategia de Gestión de la
Comunicación en cada límite de fase a fin de
asegurar que todavía incluya a todas las partes
interesadas principales. Al planificar la fase final
del proyecto también es importante revisar la
Estrategia de Gestión de la Comunicación para
asegurar que incluya a todas las partes a quien
es necesario informar de que el proyecto se está
cerrando.
Durante un proyecto, la gestión corporativa o del
programa retiene el control al recibir información
sobre el proyecto según lo definido en la Estrategia
de Gestión de la Comunicación y tomando
decisiones sobre excepciones a nivel de proyecto
presentadas por la Junta de Proyecto.
Si un proyecto forma parte de un programa, será
necesario que haya coherencia y comunicación
entre los niveles de gestión del proyecto y del
programa. Véase el Capítulo 19 para información
más detallada sobre los roles de un programa y la
manera en que podrían interactuar con los roles de
un proyecto.
 Organización | 49

5.4 Responsabilidades
La Tabla 5.1 resume las responsabilidades
pertinentes a la temática de la Organización.
Véase el Apéndice C para más detalles sobre los
roles del equipo de gestión del proyecto y sus
responsabilidades relacionadas.

Tabla 5.1 Responsabilidades pertinentes a la temática de la Organización

Rol Responsabilidades
Gestión corporativa o del programa Nombrar al Ejecutivo y (posiblemente) al Project Manager.
Proporcionar información al proyecto según lo definido en la
Estrategia de Gestión de la Comunicación.

Ejecutivo Nombrar al Project Manager (si la gestión corporativa o del programa

no lo ha hecho).

Confirmar los nombramientos al equipo de gestión del proyecto y la

estructura del equipo de gestión del proyecto.

Aprobar la Estrategia de Gestión de la Comunicación.

Usuario Principal Proporcionar los recursos del usuario.
Definir y verificar las exigencias y expectativas de los usuarios.
Proveedor Principal Proporcionar los recursos del proveedor.
Project Manager Preparar la Estrategia de Gestión de la Comunicación.
Revisar y actualizar la Estrategia de Gestión de la Comunicación.
Diseñar, revisar y actualizar la estructura del equipo de gestión del
proyecto.
Preparar las descripciones de los roles.
Team Manager Dirigir a los miembros del equipo del proyecto.
Informar sobre la participación de los miembros del equipo del
proyecto y de las partes interesadas.
Garantía del Proyecto Informar sobre la selección de miembros del equipo del proyecto.
Informar sobre la participación de las partes interesadas.
Asegurar que la Estrategia de Gestión de la Comunicación sea
apropiada y que las actividades de comunicación planificadas tengan,
de hecho, lugar.
Apoyo al Proyecto Proporcionar apoyo administrativo al equipo de gestión del proyecto.
Calidad 6
6 Calidad
6.1 Propósito
El propósito de la temática de Calidad es
definir e implementar los medios con los que
el proyecto creará y verificará productos aptos
para su propósito.
La temática de Calidad define el enfoque de
PRINCE2 para asegurar que los productos del
proyecto:
■■ Cumplan las expectativas comerciales
■■ Permitan lograr posteriormente los beneficios
deseados.
El principio de “centrarse en los productos” es
fundamental en el enfoque de PRINCE2 hacia la
calidad. Proporciona una comprensión uniforme
explícita de lo que el proyecto creará (el alcance)
y de los criterios con los que se evaluarán los
productos del proyecto (la calidad). Sin esta
comprensión, el proyecto estaría expuesto a riesgos
importantes (como disputas para la aceptación,
trabajo repetido, cambios incontrolados o
insatisfacción del usuario) que podrían debilitar o
invalidar el Business Case.
Solamente después de establecer los criterios de
calidad para los productos y las actividades de
gestión de calidad que se tienen que incluir en los
planes del proyecto, se podrán calcular los costes
y calendarios de todo el proyecto. Subestimar u
omitir actividades de gestión de calidad conduciría
probablemente a desviaciones, gastos excesivos
y/o resultados de calidad insatisfactorios. La
temática de Calidad se ocupa de los métodos y
responsabilidades de calidad, no solamente para
la especificación, desarrollo y aprobación de los
productos del proyecto, sino también para la
gestión del proyecto.
La temática de Calidad también abarca la
implementación de mejoras continuas durante
el proyecto. Por ejemplo, buscando modos de
desarrollar una mayor eficacia o eficiencia en
la gestión del proyecto y de los productos del
proyecto. Registrar y abordar lecciones contribuye
al enfoque de calidad de PRINCE2, ya que es un
modo de lograr una mejora continua.
6.2 Definición de calidad
En ocasiones, diferentes personas interpretan de
modo distinto o intercambiable los términos que
se utilizan en el contexto de la calidad. Esto puede
provocar malentendidos. En relación con PRINCE2,
la terminología utilizada deriva de las normas ISO
9000, pero se enfoca específicamente al trabajo en
proyectos.
6.2.1 Calidad
La calidad se define normalmente como la
totalidad de los rasgos y las características
inherentes o asignadas a un producto, una
persona, un proceso, un servicio y/o un sistema
que influyen en su capacidad para demostrar que
cumple las expectativas o satisface necesidades,
exigencias o una especificación determinadas.
En PRINCE2, un producto también puede ser una
persona, un proceso, un servicio y/o un sistema, por
lo que la calidad se centra en la capacidad de un
producto para cumplir con sus requerimientos.
6.2.2 Alcance
El alcance de un plan es la suma total de sus
productos. Se define en la estructura jerárquica
de productos para el plan y sus Descripciones de
Productos asociadas.
6.2.3 Gestión de calidad y sistemas de
gestión de calidad
La gestión de calidad se define como las
actividades coordinadas para dirigir y controlar una
organización en materia de calidad. Un sistema
de gestión de calidad es el conjunto completo de
normas, procedimientos y responsabilidades de
calidad para una sede u organización.
En el contexto de proyecto, “sedes” y
“organizaciones” se deberían interpretar
como la o las organizaciones permanentes o
semipermanentes que patrocinan el trabajo del
proyecto, es decir, son “externas” a la organización
temporal del proyecto. Un programa, por
ejemplo, puede considerarse una organización
semipermanente que patrocina el proyecto, y
54 | Calidad

podrá tener un sistema de gestión de calidad La garantía de calidad consiste en comprobar de

documentado. modo independiente que existen la organización
y los procesos para la planificación y control de
Con frecuencia, participará en el proyecto más
calidad (es decir, no se trata de llevar a cabo
de una organización permanente (por ejemplo,
la planificación o el control de calidad, que es
empresas separadas de cliente y proveedor) y,
algo que llevará a cabo el equipo de gestión del
como consecuencia, cada una podría tener su
proyecto). Proporciona a las partes interesadas del
propio sistema de gestión de calidad. Por otro
proyecto la seguridad de que se puede cumplir con
lado, si el proyecto tiene una sola organización
los requerimientos de calidad.
patrocinadora principal, o forma parte de un
programa, es más probable que se aplique un La expresión “garantía de calidad” se utiliza en dos
único sistema de gestión de calidad establecido. sentidos:
Estas distintas circunstancias pueden abordarse
■■ Como la función dentro de una organización (o
cuando se determina el enfoque del proyecto hacia
sede o programa) que establece y mantiene el
la calidad.
sistema de gestión de calidad
■■ Como la actividad de revisar la organización,
6.2.4 Planificación de calidad
procesos y/o productos de un proyecto para
Para controlar cualquier cosa, incluida la evaluar de modo independiente si se cumplirá
calidad, debe existir un plan. La planificación con los requerimientos de calidad.
de calidad consiste en la definición de los
productos requeridos para el proyecto, con sus Nótese que, en los dos sentidos de la expresión,
correspondientes criterios de calidad, métodos la garantía de calidad implica contribuciones que
de calidad (incluido el esfuerzo necesario son independientes del equipo de gestión del
para el control de calidad y la aceptación del proyecto, mientras que la planificación de calidad y
producto) y las responsabilidades de calidad de los el control de calidad sí que son realizados por parte
participantes. del proyecto. Sin embargo, es una responsabilidad
de la gestión del proyecto asegurarse de que se
6.2.5 Control de calidad establezca una garantía de calidad adecuada.
El control de calidad se centra en las actividades La garantía de calidad no se debe confundir con la
y técnicas operativas utilizadas por quienes Garantía del Proyecto. La Garantía del Proyecto se
participan en el proyecto para: refiere concretamente a la responsabilidad de la
Junta de Proyecto de asegurarse de que el proyecto
■■ Cumplir con las exigencias de calidad (por
se lleve a cabo de modo adecuado en todos los
ejemplo, mediante inspecciones o pruebas de
sentidos. Por lo tanto, ésta es una responsabilidad
calidad)
dentro del equipo de gestión del proyecto.
■■ Identificar formas de eliminar las causas de
Aunque la Garantía del Proyecto es independiente
rendimiento no satisfactorio (por ejemplo, del Project Manager, no es independiente del
introduciendo mejoras en los procesos como proyecto, a diferencia de la garantía de calidad. Sin
resultado de lecciones aprendidas). embargo, existen áreas comunes entre la Garantía
del Proyecto y la garantía de calidad, como muestra
6.2.6 Garantía de calidad la Tabla 6.1.
Es una práctica correcta establecer una garantía
de calidad que sea independiente del equipo
de gestión del proyecto. La garantía de calidad
proporciona una comprobación de que la
dirección y gestión del proyecto son adecuadas
a la naturaleza del proyecto y que cumplen con
las normas y políticas pertinentes de la gerencia
corporativa o del programa. Las actividades de
garantía de calidad quedan fuera del alcance
de PRINCE2, ya que son responsabilidad de la
organización corporativa o del programa.
 Calidad | 55

Tabla 6.1 La relación entre la Garantía del Proyecto y la garantía de calidad

Garantía del Proyecto Garantía de calidad

Qué hacen Proporciona a las partes interesadas del
proyecto una garantía de que el proyecto se
está llevando a cabo correctamente.
En qué se diferencian Debe ser independiente del Project
Manager, el Apoyo al Proyecto, los Team
Managers y los equipos del proyecto.
Es una responsabilidad de la Junta de
Proyecto, y por lo tanto se desempeña
dentro del proyecto.
Cómo se relacionan La Junta de Proyecto podría utilizar la
función corporativa o de programa de
garantía de calidad como parte de su
régimen de Garantía del Proyecto (por
ejemplo, haciendo que la garantía de
calidad lleve a cabo una revisión por parte
de pares).
Proporciona a la organización corporativa
o del programa más amplia una garantía
de que el proyecto se está llevando a
cabo de modo adecuado y correcto, y de
que cumple con las normas y políticas
pertinentes de la gerencia corporativa o del
programa.
La desempeña personal independiente
del proyecto (es decir, no un miembro del
equipo de gestión del proyecto).
Es una responsabilidad de la organización
de la gerencia corporativa o del programa, y
por lo tanto es externa al proyecto.
La garantía de calidad comprobaría (o
exigiría) que exista una Garantía del
Proyecto eficiente como uno de los
indicadores de que el proyecto se está
llevando a cabo correctamente.

6.3 El enfoque de PRINCE2 hacia la 6.3.1 Planificación de calidad

calidad
El tratamiento específico para la calidad en
PRINCE2 es el enfoque en los productos desde el
principio, exigiendo actividades sistemáticas para:
■■ Identificar todos los productos del proyecto
(esto es, al nivel al que el proyecto tenga
intención de ejercer control)
■■ Definirlos en las Descripciones de Productos
– incluyendo los criterios de calidad con los
que se evaluarán, los métodos de calidad que
se deben usar para su diseño, desarrollo y
aceptación y las responsabilidades de calidad de
los involucrados
■■ Implementar y hacer un seguimiento de los
métodos de calidad empleados durante todo el
proyecto.
De los dos primeros puntos se ocupa la
planificación de calidad (sección 6.3.1) y del último
se ocupan el control de calidad (sección 6.3.2) y la
garantía de calidad (sección 6.2.6).
El enfoque de PRINCE2 hacia la calidad se puede
resumir simplemente mediante la secuencia de
auditoría de calidad que se muestra en la Figura
6.1. Los términos utilizados en el diagrama se
explican en el resto de esta sección.
El propósito de la planificación de calidad es
proporcionar una base segura para:
■■ El acuerdo de la Junta de Proyecto sobre las
expectativas de calidad generales, los productos
requeridos con sus criterios de calidad asociados
(incluidas las normas corporativas y de otro
tipo con las que se deba cumplir), los medios
mediante los que se logrará y evaluará la
calidad y, en última instancia, los criterios de
aceptación con los que se juzgará el producto
del proyecto
■■ Comunicar estos acuerdos de forma inequívoca
para que todas las partes interesadas del
proyecto tengan una comprensión uniforme de
lo que se plantea lograr en el proyecto
■■ El control, es decir, establecer una baseline
efectiva para los controles de calidad del
proyecto (incluidas las tolerancias de calidad) y
un medio seguro para lograr productos aptos
para su propósito.
Si se ignoran estos aspectos de la planificación, las
personas que participan en el proyecto pueden
tener puntos de vista contradictorios sobre el
alcance de la solución, sobre lo que constituye
un resultado con éxito, sobre el enfoque que se
tiene que adoptar, sobre el alcance del trabajo
56 | Calidad

Del cliente Respuesta del proyecto

Expectativas
de calidad del cliente

Criterios de aceptación

Descripción del Estrategia de

Producto del Proyecto Gestión de la Calidad

Componentes de calidad
Planificación
Descripciones Criterios de calidad
de la calidad de Productos y tolerancias

Técnica de
planificación
basada en el Métodos de calidad

producto
de PRINCE2
Responsabilidades
de calidad

Registro de Calidad

Técnica de PRODUCTO
revisión de Control
calidad
de PRINCE2 Testimonios documentales
de calidad
de calidad y aprobación

Testimonios documentales
de aceptación

Figura 6.1 La secuencia de auditoría de calidad

requerido, sobre quién debe participar y sobre
cuáles deberían ser sus roles.
La planificación de calidad incluye:
■■ Comprender las expectativas de calidad del
cliente (sección 6.3.1.1)
■■ Definir los criterios de aceptación del proyecto
(sección 6.3.1.2)
■■ Documentar las expectativas de calidad del
cliente y los criterios de aceptación del proyecto
en la Descripción del Producto del Proyecto
(sección 6.3.1.3)
■■ Formular una Estrategia de Gestión de la
Calidad (sección 6.3.1.4)
■■ Redactar Descripciones de Productos claras
que contengan los criterios de calidad, las
tolerancias de calidad, el método de calidad y
las responsabilidades de calidad (sección 6.3.1.5)
■■ Crear el Registro de Calidad (sección 6.3.1.6).
6.3.1.1 Las expectativas de calidad del
cliente
Las expectativas de calidad del cliente son una
declaración sobre la calidad esperada para el
producto del proyecto. Se definen y acuerdan al
principio, en el proceso de la Puesta en Marcha
de un Proyecto. Las expectativas se registran
en discusiones con el cliente y se perfeccionan

para incluirlas en la Descripción del Producto del
Proyecto.
Para evitar interpretaciones incorrectas y
suposiciones imprecisas sobre las exigencias de
calidad del proyecto, las expectativas de calidad del
cliente deben abarcar:
■■ Las principales exigencias de calidad para el
producto del proyecto
■■ Cualquier norma y proceso que será necesario
aplicar para lograr los requerimientos de
calidad especificados, incluyendo la medida en
que se debería usar el sistema de gestión de
calidad del cliente y/o del proveedor
■■ Cualquier medición que podría ser útil para
evaluar si el producto del proyecto cumple con
los requerimientos de calidad (por ejemplo,
mediciones existentes de la satisfacción del
cliente).
Los principales requerimientos de calidad
determinarán la elección de la solución y,
en consecuencia, influirán en las metas de
rendimiento de tiempo, coste, alcance, riesgo y
beneficio del proyecto.
Ejemplos de expectativa de calidad
La expectativa de calidad para una bomba
de agua en un pueblo remoto es que sea lo
suficientemente resistente para “durar toda una
vida”, mientras que una bomba de aceite de un
coche de carreras necesita ser tan ligera como
sea posible y, por lo tanto, puede que solamente
sea necesario que dure una carrera.
Las expectativas de calidad del cliente se expresan
a menudo en sentido amplio para proporcionar
una comprensión uniforme de los requerimientos
de calidad generales. Se utilizan para identificar
criterios de aceptación más detallados, que
deberían ser específicos y precisos.
Siempre que sea posible, se debe dar prioridad a
las expectativas de calidad del cliente, ya que se
usarán como aportes para definir las tolerancias de
calidad para los productos del proyecto.
Las expectativas de calidad del cliente se revisarán
al final de cada fase de gestión por si algún factor
externo las ha modificado.
6.3.1.2 Criterios de aceptación
Los criterios de aceptación del proyecto constituyen
una lista ordenada por prioridad de definiciones
Calidad | 57
medibles de los atributos requeridos para que
un conjunto de productos sea aceptable para las
principales partes interesadas. Algunos ejemplos
son: la facilidad de utilización, facilidad de apoyo,
facilidad de mantenimiento, apariencia, funciones
principales, costes de desarrollo, costes operativos,
capacidad, disponibilidad, fiabilidad, seguridad,
precisión y rendimiento.
Los criterios de aceptación deberían estar
ordenados por prioridad, ya que esto ayuda si se
tiene que sopesar la importancia de varios criterios.
Por ejemplo, puede que una alta calidad, una
entrega rápida y un bajo coste no sean compatibles
y podría ser necesario sacrificar uno para lograr los
otros dos.
Ejemplo de una técnica de ordenación por
prioridad - DDPN
Cada criterio de aceptación se clasifica como
algo que se Debe obtener, se Debería obtener,
se Podría obtener o No se obtendrá por ahora
(DDPN).
Debería ser posible lograr todos los criterios de
aceptación del tipo “Debe obtener” y “Debería
obtener” sin que se excluyan entre sí.
Cuando el proyecto puede demostrar que se han
logrado todos los criterios de aceptación, se habrá
cumplido con las obligaciones del proyecto y se
podrá cerrar el proyecto.
Los criterios de aceptación deberían ser acordados
entre el cliente y el proveedor durante el
proceso de la Puesta en Marcha de un Proyecto y
documentados como parte de la Descripción del
Producto del Proyecto. Es importante tener en
cuenta que posiblemente la comprensión de los
productos del proyecto sea limitada en esta etapa
tan temprana. Por lo tanto, a menudo los criterios
de aceptación se perfeccionarán y acordarán
durante el proceso del Inicio de un Proyecto y se
revisarán al final de cada fase de gestión. Una
vez han sido completados en la Descripción del
Producto del Proyecto, los criterios de aceptación
están sujetos a control de cambios y solamente se
pueden cambiar si se cuenta con la aprobación de
la Junta de Proyecto.
Al considerar los criterios de aceptación, resulta útil
seleccionar mediciones sustitutivas que constituirán
indicadores precisos y fiables sobre si se lograrán
los beneficios posteriormente.
58 | Calidad
Ejemplo de criterios de aceptación
Si la expectativa de calidad del cliente para una
bomba de agua es que “dure toda una vida”,
los criterios de aceptación se deberían centrar
en aquellas mediciones que proporcionen la
seguridad o indicación suficientes de que la
bomba puede durar toda una vida (definiéndose
ésta como un número de años específico). Esto
puede incluir el cumplimiento de determinadas
normas de ingeniería relativas a la durabilidad
del producto.
La identificación de los métodos de aceptación
es fundamental porque responden a la siguiente
pregunta: ¿cómo probamos si el producto del
proyecto ha sido completado, cuándo ha sido
completado y si es aceptable para el cliente?
6.3.1.3 La Descripción del Producto del
Proyecto
La Descripción del Producto del Proyecto se crea en
el proceso de la Puesta en Marcha de un Proyecto
como parte de la actividad de determinación inicial
del alcance y se puede perfeccionar durante el
proceso del Inicio de un Proyecto cuando se crea
el Plan de Proyecto. Está sujeta a un control de
cambios formal y se debería revisar en los límites
de fase (durante el proceso de la Gestión de los
Límites de Fase) para ver si se requieren cambios.
Se utiliza en el proceso del Cierre de un Proyecto
como parte de la verificación de que el proyecto
ha entregado lo que se esperaba de él y que se ha
cumplido con los criterios de aceptación.
La Descripción del Producto del Proyecto incluye:
■■ El propósito general del producto
■■ Su composición (es decir, el conjunto de
productos que tiene que incluir)
■■ Las expectativas de calidad del cliente
■■ Los criterios, método y responsabilidades de
aceptación
■■ Las tolerancias de calidad a nivel de proyecto.
La Descripción del Producto del Proyecto aprobada
se incluye como un componente del Expediente
del Proyecto y se utiliza para ayudar a elegir el
enfoque del proyecto. La Descripción del Producto
del Proyecto define lo que el cliente espera que
el proyecto entregue y el enfoque del proyecto
define la solución o método que el proveedor tiene
que utilizar para crear el producto del proyecto.
La Descripción del Producto del Proyecto es un
tipo especial de Descripción de Producto, en el
sentido de que incluye las expectativas de calidad
del cliente y, a este nivel, los criterios de calidad
y los métodos de calidad constituyen los criterios
de aceptación y los métodos de aceptación para la
totalidad del proyecto.
6.3.1.4 La Estrategia de Gestión de la
Calidad
La Estrategia de Gestión de la Calidad se prepara
durante el proceso del Inicio de un Proyecto y es
posteriormente aprobada por la Junta de Proyecto.
Complementa el enfoque del proyecto y se puede
considerar como las propuestas del equipo de
gestión del proyecto en respuesta a las expectativas
de calidad y los criterios de aceptación del cliente.
La Estrategia de Gestión de la Calidad describe el
modo en el que los sistemas de gestión de calidad
de las organizaciones participantes se aplicarán al
proyecto y confirma las normas, procedimientos,
técnicas y herramientas de calidad que se
utilizarán. Cuando se tengan que adaptar modelos
y normas, la adaptación debería estar también
resumida en la Estrategia de Gestión de la Calidad
para su aprobación.
La Estrategia de Gestión de la Calidad también
proporciona un medio para medir y acordar según
las necesidades específicas del proyecto los niveles
de formalidad que se deberán aplicar a los planes y
controles de calidad.
Debería resumir los acuerdos sobre la garantía
de calidad, incluyendo auditorías independientes
en los casos en que éstas sean requeridas por las
políticas de las organizaciones participantes.
Se deberían definir las principales
responsabilidades de calidad (tanto dentro
como fuera del equipo de gestión del proyecto),
incluyendo un resumen del enfoque para la
Garantía del Proyecto.
Cuando ya exista un sistema de gestión de calidad
establecido para proyectos (por ejemplo, en un
programa), solamente es necesario documentar las
mediciones específicas para este proyecto.
La Estrategia de Gestión de la Calidad, sujeta a
control de cambios, se mantiene durante la vida
del proyecto.

6.3.1.5 Descripciones de Productos
Una vez que está en marcha la planificación
detallada, se deberían crear Descripciones de
Productos para todos los productos del proyecto.
Las Descripciones de Productos no son opcionales.
Regulan el desarrollo de los productos y su
posterior revisión y aprobación.
El grado de detalle en una Descripción de Producto
es algo que se debe considerar con el objetivo
principal de seleccionar un grado de detalle que
proporcione una medición de control segura y
apropiada, que sea suficiente para cumplir con las
expectativas de calidad del cliente.
El contenido de una Descripción de Producto
está descrito en su totalidad en el Apéndice A.
La sección de “propósito” de la Descripción de
Producto debería indicar claramente quiénes
necesitan el producto, por qué lo necesitan y
qué función tendrá. Además del “propósito”, las
secciones relacionadas específicamente con la
calidad son: criterios de calidad, tolerancias de
calidad, métodos de calidad, competencias de
calidad requeridas y responsabilidades de calidad.
Éstas definen los controles de calidad que se deben
aplicar durante el desarrollo del producto y en los
procedimientos de revisión y aprobación para el
producto completado.
Se debería tener cuidado de no redactar las
Descripciones de Productos con un grado de
detalle excesivo. Existen para proporcionar
ayuda a los métodos de planificación, desarrollo,
calidad y aprobación. Las Descripciones de
Productos demasiado detalladas pueden conducir
a un aumento innecesario del coste de calidad
del proyecto. Las Descripciones de Productos
incompletas o imprecisas pueden conducir a
disputas sobre la aceptación si los resultados
entregados no cumplen con las expectativas del
cliente. Cuando sea necesario, la Descripción de
Producto debería hacer referencia a información
de apoyo, como normas o documentos de diseño
especializados que puedan ser de aplicación.
El tiempo necesario para crear Descripciones
de Productos adecuadas dependerá de factores
como la importancia, complejidad y singularidad
del producto, la cantidad de partes interesadas
que revisarán y aprobarán el producto y si la
organización tiene una biblioteca de Descripciones
de Productos estándar para su reutilización. A
menudo, los usuarios de PRINCE2 implementan
Calidad | 59
bibliotecas de Descripciones de Productos para
fomentar la coherencia y la reutilización.
Criterios de calidad
La Descripción de Producto debería incluir las
especificaciones de calidad con las que el producto
debe cumplir y las mediciones de calidad que
aplicarán quienes inspeccionen el producto
terminado.
Los criterios de calidad deberían ser
suficientemente detallados y claros para permitir
a quienes revisen un producto confirmar de
modo inequívoco si el producto cumple con sus
exigencias.
Ejemplo de criterios de calidad
Pensemos en un proyecto para diseñar y fabricar
una nueva cámara fotográfica. Un criterio
de calidad es que la cámara y su embalaje no
pesen más de 1 kg. La estructura jerárquica
de productos identifica como producto un
manual del usuario. La consecuencia es que el
tamaño y peso del manual del usuario es un
factor importante pero no lo es, por ejemplo, el
número de páginas.
Las preguntas que se tendrían que plantear
incluyen: ¿Cuál es el mercado objetivo para la
cámara? ¿Implica esto que el manual también
tiene que estar redactado en varios idiomas?
¿Significará eso que pesará más? ¿O será
suficiente un manual en formato CD-ROM? Esto
podría reducir el peso del manual y permitir que
la propia cámara pese más.
La consideración de los criterios de calidad
a menudo pone de manifiesto conexiones y
factores como éstos, que aportan información al
proceso de planificación posterior.
Tolerancias de calidad
Las tolerancias de calidad para un producto se
pueden especificar en los criterios de calidad
mediante la definición de un intervalo aceptable
de valores. Por ejemplo: “¿La duración de la
presentación es de 30 minutos (más/menos 5
minutos)?”, “¿Se mantiene la temperatura en el
intervalo de 1ºC a 5ºC?”
60 | Calidad

Métodos de calidad 6.3.1.6 El Registro de Calidad

La sección de métodos de calidad de la Descripción El Registro de Calidad cumple la función de agenda
de Producto se utiliza para especificar las actividades de los eventos de calidad planificados y llevados a
de calidad que se deben implementar durante cabo (por ejemplo, talleres de trabajo, revisiones,
el desarrollo de un producto, para su revisión y inspecciones, pruebas, productos piloto, aceptación
aprobación cuando haya sido completado. Cuando y auditorías). Se crea durante el proceso del Inicio
existan competencias especializadas implícitas en de un Proyecto a medida que se van definiendo los
los métodos de calidad, éstas también deberían productos y las mediciones de control de calidad.
especificarse. Existen dos tipos principales de Posteriormente, se mantiene (en línea con las
métodos de calidad: métodos en proceso y métodos versiones baseline actuales de los planes) durante
de evaluación (véase la sección 6.3.2.1). todo el proyecto.

Responsabilidades de calidad A medida que avanza el proyecto y se reciben

Para evitar cualquier duda, las responsabilidades testimonios documentales de las actividades de
de calidad para un producto deberían ser calidad, el Registro de Calidad se actualiza para
especificadas. Las responsabilidades pertenecerán a reflejar (de forma resumida) los resultados reales
una de estas tres categorías: de las actividades de calidad. El Registro de Calidad
proporciona información fundamental para la
■■ Productor La persona o el grupo responsable auditoría y la garantía, relacionando lo que se
de desarrollar un producto planeó y acordó (en la Estrategia de Gestión de la
■■ Revisor(es) Una persona o grupo Calidad y las Descripciones de Productos) con las
independiente del productor que evalúa si un actividades de calidad que realmente se llevan a
producto cumple con sus requerimientos según cabo.
lo definido en su Descripción de Producto
La cantidad de información incluida en el Registro
■■ Aprobador(es) La persona o el grupo (por ej.
de Calidad puede variar considerablemente,
una Junta de Proyecto) identificados como
dependiendo de la medida en que las mediciones
cualificados y autorizados para aprobar un
de calidad (por ejemplo, “cuentas de defectos”)
producto como completo y apto para su
necesitan ser analizadas para la mejora de los
propósito.
procesos. En la Tabla 6.2 se muestra un ejemplo de
un Registro de Calidad.
Tabla 6.2 Ejemplo de un Registro de Calidad
Fecha de Aprobación
Fecha de Aprobación
Método de Calidad

Fecha de Revisión

Fecha de Revisión
ID de la Actividad

ID del Producto

Aprobador(es)
Revisor(es)

Planificada

Resultado
Planificada
Productor
Producto

Real

Real

1 121 Plan de Inspección Ali Paulo John, 14-Feb 21-Feb 21-Feb 28-Feb Aprobada
Pruebas Rita

2 124 Bomba Prueba de Paulo Ali, John 20-Mar 20-Mar 27-Mar N/C No
de Agua Rendimiento Bob Aprobada

3 124 Bomba Prueba de Paulo Ali, Rita 21-Mar 21-Mar 27-Mar 27-Mar Aprobada
de Agua Mantenimiento Amir

. . . . . . . . . . . .
. . . . . . . . . . . .
9 124 Bomba Prueba de Paulo Ali, John 14-Jun 21-Jun
de Agua Rendimiento Bob

6.3.2 Control de calidad
El control de calidad se consigue implementando,
haciendo un seguimiento y registrando los
métodos y responsabilidades de calidad definidos
en la Estrategia de Gestión de la Calidad y en las
Descripciones de Productos (y posteriormente
acordados en Paquetes de Trabajo).
El control de calidad incluye:
■■ Llevar a cabo los métodos de calidad (sección
6.3.2.1)
■■ Mantener testimonios documentales de calidad
y aprobación (secciones 6.3.2.2 y 6.3.2.3)
■■ Obtener la aceptación (sección 6.3.2.4).
6.3.2.1 Métodos de calidad
El coste de corregir defectos en los productos
es mayor cuanto más tiempo permanezcan sin
ser detectados. Es mucho más fácil y económico
corregir un documento de diseño al principio del
proyecto que corregir un defecto de diseño que
no se descubre hasta que el producto terminado
se prueba o, aún peor, cuando el producto
ya está en funcionamiento. Por lo tanto, las
inspecciones de calidad, implementadas desde el
principio en los procesos de diseño y desarrollo,
son potencialmente los métodos de calidad más
económicos de los que se dispone.
Existen dos tipos de métodos de calidad:
■■ Métodos “en proceso” Estos son los medios
mediante los que la calidad se puede
“incorporar” a los productos a medida que se
desarrollan. Estos podrían implicar el uso de
métodos y/o técnicas especializados, incluyendo
controles de proceso calibrados, automatización
(por ejemplo, robótica, herramientas de
software), ejercicios piloto, talleres de trabajo,
estudios y consultas o, de modo más simple,
el uso de inspecciones de calidad durante
el desarrollo del producto, así como en el
momento de su terminación
■■ Métodos de evaluación Estos son los medios
mediante los que se evalúan los productos
terminados para comprobar que están
completos y son aptos para su propósito.
Existen, fundamentalmente, dos tipos de
métodos de evaluación, dependiendo de la
medida en que sea posible definir criterios de
calidad objetivos: pruebas (si los criterios de
calidad son realmente objetivos y cuantificables)
Calidad | 61
o inspección de calidad (si es necesario hacer
algún tipo de juicio subjetivo).
Una inspección de calidad es una evaluación
sistemática y estructurada de un producto,
realizada de forma planificada, documentada
y organizada. Se puede utilizar un enfoque
sistemático pero flexible para la inspección de
calidad:
■■ Durante el desarrollo de productos de este tipo,
ya sea de modo formal (es decir, en línea con lo
acordado durante la planificación de calidad) o
de modo informal (simplemente como un modo
de evaluar la calidad de un “trabajo en curso”)
■■ Para marcar la terminación y aprobación de
productos
■■ Para complementar las pruebas (por ejemplo,
simplemente para comprobar resultados de
pruebas).
Las técnicas de inspección de calidad son de
aplicación particularmente cuando se necesita un
juicio profesional para evaluar si el producto es
apto para su propósito. Las técnicas se pueden
utilizar dentro del proyecto, como controles de
calidad, o por parte de expertos independientes,
como parte de la garantía de calidad. Las revisiones
por parte de pares y revisiones en los puntos
claves son ejemplos de actividades de garantía de
calidad que se pueden implementar utilizando o
adaptando una técnica de inspección genérica.
Utilizada como un control del equipo de gestión
del proyecto, la realización de inspecciones de
calidad sistemáticas también puede tener valiosos
beneficios adicionales en las relaciones dentro de
los equipos.
Incluso cuando las pruebas son el método de
evaluación principal, a menudo alguien tiene
que comprobar que los resultados de las pruebas
cumplen con los criterios para su éxito y, por lo
tanto, sigue siendo necesaria una inspección
simple.
Existen varias técnicas de inspección sistemáticas,
algunas de las cuales son específicas de ciertos
tipos de producto o sectores. PRINCE2 permite el
uso de estas técnicas, pero también proporciona
una técnica de revisión de calidad muy útil que
complementa el uso de las Descripciones de
Productos de PRINCE2.
62 | Calidad
La técnica de revisión de calidad de PRINCE2
Objetivos
■■ Evaluar la conformidad de un producto que
toma la forma de documento (u elemento
similar, como por ejemplo una presentación
o los resultados de una prueba) utilizando
criterios establecidos
■■ Hacer participar a las principales partes
interesadas en la comprobación de la calidad
del producto y en el fomento de una mayor
aceptación del producto
■■ Proporcionar la confirmación de que el
producto está completo y listo para su
aprobación
■■ Crear la versión baseline del producto que se
usará para el control de cambios.
Roles del equipo de revisión
■■ Presidente Este rol es responsable de la
conducción general de la revisión
■■ Presentador Este rol presenta el producto
para su revisión y representa al productor
o productores del producto. El presentador
también coordina y hace un seguimiento
del trabajo después de la revisión, esto es,
aplicando los cambios al producto acordados
por el equipo
■■ Revisor Este rol revisa el producto, remite
preguntas y confirma las correcciones y/o las
mejoras
■■ Administrador Este rol proporciona apoyo
administrativo al presidente y registra el
resultado y las acciones.
En la forma mínima de revisión (utilizada
para inspecciones simples, como por ejemplo
inspecciones de resultados de pruebas)
participan solamente dos personas: una adopta
los roles de presidente y revisor y la otra los roles
de presentador y administrador.
Nota: la revisión de calidad es una técnica
genérica que se puede utilizar fuera del contexto
del proyecto. Por lo tanto, los roles de revisión
de calidad no guardan una relación específica
con los roles de la estructura del equipo de
gestión del proyecto. Sin embargo, se pueden
materializar beneficios para las relaciones dentro
de los equipos si los Project Managers y los Team
Managers presiden revisiones regularmente.
Presidir revisiones de calidad requiere
competencias de facilitación y la independencia
del producto que se revisa (la responsabilidad
principal es asegurarse de que la revisión se
lleve a cabo correctamente).
Preparación de la revisión
■■ Realizar los acuerdos administrativos
necesarios para la revisión (presidente/
administrador)
■■ Comprobar que el producto está listo para la
revisión y confirmar la disponibilidad de los
revisores (presidente)
■■ Distribuir copias del producto y de la
Descripción de Producto correspondiente
al equipo de revisión, dejando tiempo
de preparación suficiente a los revisores
(presentador)
■■ Revisar el producto en base a los criterios
de calidad de la Descripción de Producto
asociada (revisores)
■■ Presentar una lista de preguntas al
presidente y al presentador antes de la
revisión (revisores)
■■ Hacer anotaciones en la copia del producto
cuando existan errores de ortografía o
gramática y devolverla al presentador
(revisores)
■■ Preparar una lista consolidada de preguntas
(presidente) y enviarla al presentador antes
de la reunión.
Revisión del orden del día de la reunión
■■ Presentaciones del personal, si son necesarias
(presidente)
■■ Presentación del producto (presentador) Un
resumen muy breve, que cubra el propósito
del producto: quiénes lo necesitan, por qué
lo necesitan y cuál será su función
■■ Preguntas importantes/globales (presidente)
Invitar a cada revisor a contribuir con
cualquier pregunta importante o global
sobre el producto. Las preguntas globales
son las que aparecen repetidamente para
todo el producto. El equipo de revisión
acuerda las acciones para cada pregunta
que se plantee. El administrador registra las
acciones y las responsabilidades
■■ Discusión guiada sobre el producto
(presentador) Guiar al equipo de revisión
por todo el producto, sección por sección o
página por página (según resulte apropiado),

revisando la lista consolidada de preguntas
e invitando a que se hagan aclaraciones
cuando sea necesario. El equipo de revisión
acuerda las acciones para cada pregunta
que se plantee. El administrador registra las
acciones y las responsabilidades
■■ Comprobación de las acciones acordadas
(administrador) Confirmar las acciones y
responsabilidades
■■ Resultado de la revisión (presidente) Guiar
al equipo de revisión hacia una decisión
colectiva. Los posibles resultados son:
●● Completo (el producto, tal y como está, es
apto para su propósito)
●● Completo con condiciones (el producto es
apto para su propósito con la condición
de que se completen las acciones
acordadas)
●● Incompleto (el producto requiere otro
ciclo de revisión de calidad)
■■ Cierre de la revisión (presidente)
■■ Informar del resultado a las partes
interesadas (presidente).
Seguimiento de la revisión
■■ Coordinar las acciones (presentador)
■■ Asignar acciones individuales (revisores,
según lo acordado en la reunión)
■■ Cuando todas las acciones hayan sido
completadas, ratificar que el producto ya
está completo (presidente)
■■ Comunicar el resultado final de la revisión
de calidad a los managers o al personal de
apoyo correspondientes (administrador)
■■ Almacenar los testimonios documentales de
calidad (administrador)
■■ Solicitar la aprobación para el producto
(presentador).
Consejos y recomendaciones
■■ Revisores Revisar el producto, no la persona.
Esto significa evitar la personalización de
cuestiones (“Tú…”) y actuar como un equipo
(“Nosotros…”)
■■ Revisores Actuar como un equipo pero
remitir lo necesario a áreas de conocimiento
especializado. Puede seleccionarse a algunos
revisores para abordar aspectos específicos
del producto y puede considerarse que sus
comentarios tienen más peso en esas áreas
Calidad | 63
■■ Revisores No plantear temas superficiales
en las revisiones (ortografía, puntuación,
etc.), salvo que se trate de una cuestión
importante/global (por ejemplo, si el
documento será presentado a destinatarios
importantes, como el público en general)
■■ Presidente Procurar que el presentador
mantenga un buen ritmo durante la
discusión sobre el producto. Los revisores
deben tener la oportunidad de presentar
sus cuestiones pero permitir que se dedique
demasiado tiempo favorece que se hagan
comentarios que de otro modo no se harían.
El presentador tendría que evitar discusiones
innecesarias
■■ Presidente Resolver cada punto planteado
obteniendo una decisión del equipo de
revisión. ¿Se tiene que cambiar el producto
o no? No permitir que se desvíen las
discusiones. Es importante recordar que
el propósito de la revisión es identificar
defectos, no diseñar soluciones para éstos.
Evitar la tentación de formular y acordar
soluciones. Esto se hará después de la
revisión
■■ Presidente Centrarse en este producto. No
permitir que la discusión se desvíe a otros
productos relacionados. Si parece que podría
haber un problema asociado a un producto
relacionado, abordarlo como cuestión fuera
de la reunión
■■ Presidente Asegurarse de que los revisores
contribuyan de modo efectivo. Es su
responsabilidad asegurarse de que el
producto aprobado sea apto para su
propósito
■■ Presidente Si algún revisor no puede asistir
a la reunión, aceptar su lista de preguntas
y plantear las preguntas en su nombre,
aceptar un delegado o sustituir al revisor
■■ Presentador Es posible que no sea viable
implementar una acción de seguimiento o
que ésta no se pueda realizar dentro de las
tolerancias acordadas, en cuyo caso se debe
plantear una cuestión al Project Manager
■■ Aprobador Si la persona (o grupo) que
aprobará el producto participa en la revisión
de calidad, puede ser posible aprobar el
producto como parte de la revisión.
64 | Calidad
La aprobación formal de un producto puede o
no ser consecuencia de una revisión de calidad.
Los productos que han sido autorizados como
completados en una inspección o revisión todavía
pueden tener que presentarse a otra autoridad
diferente para su aprobación.
La técnica de revisión de calidad de PRINCE2 (así
como otras técnicas de inspección de calidad)
pueden aportar importantes beneficios adicionales,
especialmente en lo referente a:
■■ Compromiso con las partes interesadas
Las inspecciones de calidad constituyen
oportunidades para una comunicación
interfuncional eficaz. Muchas partes interesadas
importantes pueden tener solamente contacto
directo con el proyecto a través de estas
revisiones por lo que éstas proporcionan una
“ventana” al proyecto. Esto es especialmente
cierto en el caso de los usuarios. Las
inspecciones de calidad estructuradas se
encuentran entre las formas más eficaces de
fomentar una actitud positiva hacia el proyecto.
Generalmente, cuanto más sistemáticas y
eficaces sean las revisiones, mejor impresión se
dará a las partes interesadas
■■ Liderazgo En muchas ocasiones, centrarse en
la calidad (entendida como hacer que algo
sea “apto para su propósito”) resulta en una
mejor respuesta por parte de los miembros del
equipo de revisión (y los usuarios) que centrarse
simplemente en presupuestos y cronogramas.
Las técnicas de inspección de calidad
proporcionan a menudo consejos excelentes y
“guías informales” sobre la toma de decisiones
y el comportamiento eficaces en las reuniones
■■ Creación de equipos Las inspecciones de
calidad formales e informales constituyen
oportunidades para centrarse en el desarrollo
de las relaciones eficaces dentro de un equipo
del proyecto, de modo que los miembros
entiendan las contribuciones, necesidades y
prioridades de los demás miembros
■■ Personas en situación de desarrollo Los
principiantes aprenden del personal más
experimentado y detectan omisiones de
aspectos que otros dan por sentado. El personal
experimentado aprende de la visión más actual
que aportan los recién llegados
■■ Documentación de calidad Los testimonios
documentales de calidad coherentes y familiares
fomentan mejoras en la comunicación y en el
análisis de las mediciones de calidad
■■ Cultura de calidad La técnica de revisión de
calidad de PRINCE2 es genérica. Se puede
utilizar en programas, proyectos y servicios a lo
largo y ancho de una organización, lo que tiene
como resultado una “cultura de la calidad”
positiva y familiar.
6.3.2.2 Testimonios documentales de calidad
Es importante reunir pruebas que demuestren que
se han llevado a cabo las actividades de calidad
planificadas. Los testimonios documentales sirven
como base para las anotaciones en el Registro de
Calidad, proporcionando al Project Manager y a la
Junta de Proyecto la garantía de que:
■■ Los productos han sido realmente completados
(y, en consecuencia, que las actividades
relacionadas han finalizado)
■■ Los productos han cumplido con sus criterios de
calidad asociados y son aptos para el propósito
que les corresponde (o bien, existen testimonios
documentales de los fracasos en la calidad y las
rectificaciones)
■■ Se han seguido los procesos acordados
■■ Las autoridades de aprobación y las principales
partes interesadas del producto están
satisfechas
■■ Se han realizado las auditorías planificadas y se
han presentado informes sobre ellas.
Los testimonios documentales de calidad
deberían incluir referencias a la documentación
de inspección de calidad como, por ejemplo, un
plan de pruebas; los datos de cualquier estadística
de “defectos” y las acciones necesarias para
corregir errores y omisiones en los productos
inspeccionados; y cualquier informe relacionado
con la calidad (por ejemplo, una auditoría).
Cuando el Apoyo al Proyecto recibe estos
testimonios documentales, se pueden completar
las anotaciones del Registro de Calidad para los
productos correspondientes. Durante el proyecto y
al cierre del proyecto, los testimonios documentales
de calidad proporcionan una valiosa fuente de
información para el análisis de acuerdo con el
principio de PRINCE2 de que los proyectos deberían
“aprender de la experiencia”. Por ejemplo, las
mediciones de calidad, como tipos y tendencias
de defectos, se pueden utilizar como fuente para
lecciones aprendidas y mejoras en los procesos.
 Calidad | 65

6.3.2.3 Testimonios documentales de 6.4 Responsabilidades

aprobación La Tabla 6.3 resume las responsabilidades
Mientras que los testimonios documentales de relacionadas con la temática de Calidad. Véase
calidad proporcionan pruebas de que cada producto el Apéndice C para más información sobre los
ha cumplido con sus exigencias según lo especificado roles del equipo de gestión del proyecto y sus
en su Descripción de Producto, constituye una responsabilidades asociadas.
práctica correcta obtener un testimonio documental
de que el producto ha sido aprobado.
PRINCE2 no especifica el formato o la composición
de los testimonios documentales de aprobación,
ya que éstos dependerán del nivel de formalidad
requerido, la relación entre el cliente y el
proveedor y el sistema de gestión de calidad de
las organizaciones participantes. El formato de los
testimonios documentales de aprobación podría
incluir, por ejemplo, una nota en el acta de una
reunión, un correo electrónico, una carta, una firma
en un documento o un certificado.

6.3.2.4 Testimonios documentales de

aceptación
Los productos se aprueban a lo largo de la vida
del proyecto y su propiedad puede incluso ser
transferida al cliente como parte de una entrega
por fases. Pero, durante el proceso del Cierre de
un Proyecto, es importante comprobar que se han
obtenido todos los formularios de aprobación y
se han guardado testimonios documentales para
auditorías y/o asuntos contractuales.
PRINCE2 usa el término “aceptación” para describir
la aprobación última del producto del proyecto.
A menudo, es necesaria la aprobación por parte
de más de un grupo de partes interesadas. Por
ejemplo, quienes utilizan los productos del
proyecto y quienes los mantienen (en este caso,
ambas categorías de partes interesadas deberían
haber participado en la definición de los productos
correspondientes, tomando parte en inspecciones
de calidad y dando su aprobación durante el
proyecto).
La aceptación puede hacerse con reservas, y se
pueden otorgar “concesiones” documentadas
(por ejemplo, si existen defectos en la solución o
algunos criterios de rendimiento no se han logrado
en su totalidad). Cuando la Junta de Proyecto
ha otorgado concesiones, puede ser necesario
recomendar acciones de seguimiento para
mejoras o remedios posteriores para los productos
correspondientes.
66 | Calidad

Tabla 6.3 Responsabilidades relacionadas con la temática de Calidad

Rol Responsabilidades
Gerencia corporativa Proporcionar información del sistema de gestión de calidad corporativo o del programa.
o del programa Proporcionar la garantía de calidad.
Ejecutivo Aprobar la Descripción del Producto del Proyecto.
Aprobar la Estrategia de Gestión de la Calidad.
Confirmar la aceptación del producto del proyecto.
Usuario Principal Proporcionar las expectativas de calidad y los criterios de aceptación del cliente.
Aprobar la Descripción del Producto del Proyecto.
Aprobar la Estrategia de Gestión de la Calidad.
Aprobar las Descripciones de Productos para los productos del usuario.
Proporcionar recursos a nivel usuario para llevar a cabo las actividades de calidad y de aprobación
de productos.
Proporcionar la aceptación del producto del proyecto.
Proveedor Principal Aprobar la Descripción del Producto del Proyecto (si corresponde).
Aprobar la Estrategia de Gestión de la Calidad.
Aprobar los métodos, técnicas y herramientas de calidad adoptados en el desarrollo del producto.
Proporcionar recursos para llevar a cabo las actividades de calidad del proveedor.
Aprobar las Descripciones de Productos de los productos especializados principales.
Project Manager Documentar las expectativas de calidad y los criterios de aceptación del cliente.
Preparar la Descripción del Producto del Proyecto (con los usuarios).
Preparar la Estrategia de Gestión de la Calidad.
Preparar y mantener las Descripciones de Productos.
Asegurarse de que los Team Managers implementen las medidas de control de calidad acordadas
en las Descripciones de Productos y en los Paquetes de Trabajo.
Team Manager Crear productos que sean coherentes con las Descripciones de Productos.
Gestionar controles de calidad para los productos que correspondan.
Preparar los testimonios documentales de calidad.
Asesorar al Project Manager sobre el estado de la calidad del producto.
Garantía del Proyecto Asesorar al Project Manager sobre la Estrategia de Gestión de la Calidad.
Asistir a la Junta de Proyecto y al Project Manager mediante la revisión de las Descripciones de
Productos.
Asesorar al Project Manager sobre revisores/aprobadores de calidad adecuados.
Proporcionar garantías a los miembros de la Junta de Proyecto para la implementación de la
Estrategia de Gestión de la Calidad, es decir, para llevar a cabo correctamente los procedimientos
de calidad y de gestión del proyecto.
Apoyo al Proyecto Proporcionar apoyo administrativo para los controles de calidad.
Mantener el Registro de Calidad y los testimonios documentales de calidad.
Ayudar a los Team Managers y a los miembros del equipo en la aplicación de los procesos de
calidad del proyecto.
Planes 7
7 Planes

7.1 Propósito Estas metas incluirán los productos, calendarios,

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).
La gestión de proyectos eficaz se basa en una
planificación eficaz, ya que sin un plan no existe
control. La planificación proporciona, a todo el
personal que participa en el proyecto, información
sobre:
■■ Qué se requiere
■■ Cómo se logrará y quién lo logrará, utilizando
qué equipamientos especializados y recursos
■■ Cuándo tendrán lugar eventos
■■ Si es posible lograr las metas (de tiempo, coste,
calidad, alcance, riesgo y beneficios).
El desarrollo y mantenimiento de planes
verosímiles proporciona una baseline con la que
se puede medir el progreso. Posibilitan que la
información de planificación se distribuya a las
partes interesadas para garantizar los compromisos
necesarios para apoyar el plan.
La propia acción de planificar ayuda a que el
equipo de gestión del proyecto sea previsor
y “ensaye el proyecto mentalmente”. Ese
ensayo es el que posibilita que se identifiquen y
gestionen omisiones, duplicidades, amenazas y
oportunidades.
La temática de Planes proporciona un marco para
diseñar, desarrollar y mantener los planes del
proyecto (Plan de Proyecto, Planes de Fase y Planes
del Equipo).
costes, calidad y beneficios del proyecto.
Por lo tanto, un plan debe contener información y
detalles suficientes para confirmar que es posible
lograr las metas.
Los planes son la columna vertebral del sistema
de información de gestión requerido para
cualquier proyecto. Es importante que los planes se
mantengan en línea con el Business Case en todo
momento. Un plan requiere la aprobación y el
compromiso de los niveles pertinentes del equipo
de gestión del proyecto.
7.2.2 ¿Qué es la planificación?
La planificación es la acción o proceso de elaborar
y mantener un plan. El término también se
utiliza para describir los procedimientos formales
utilizados en este ejercicio, como la creación de
documentos y diagramas. La planificación es
esencial, independientemente del tipo o tamaño
de proyecto. No es un ejercicio superficial, sino que
es fundamental para el éxito del proyecto.
Sin una planificación eficaz, el resultado de
proyectos complejos no se puede predecir en
términos de alcance, calidad, riesgo, calendarios,
coste y beneficios. Quienes participan en la
provisión de recursos no pueden optimizar sus
operaciones.
Los proyectos mal planificados causan frustración,
desperdicio y trabajo repetido. Por lo tanto, es
fundamental asignar tiempo suficiente a la fase de
planificación.
PRINCE2 requiere un enfoque de la planificación
basado en el producto.

7.2 Definición de los planes

7.2.1 ¿Qué es un plan?

Cuando se pide describir un plan, mucha gente
piensa en gráfico con cronográmas.
Un plan de PRINCE2 abarca más que eso. Es un
documento que describe cómo, cuándo y quién
logrará una meta o conjunto de metas específicas.
70 | Planes
7.2.3 Niveles de planificación
Todos los aspectos de la planificación se vuelven
más difíciles cuanto más se extienden en el
tiempo. El período de tiempo para el que es
posible planificar de modo preciso se conoce como
horizonte de planificación. Por esto, raramente
será deseable o posible planificar detalladamente
un proyecto entero desde el principio. Por lo tanto,
se tienen que crear planes a distintos niveles de
alcance y detalle (véase la sección 2.4).
PRINCE2 recomienda tres niveles de plan para
reflejar las necesidades de los distintos niveles
de gestión que participan en el proyecto, fase y
equipo. Se puede consultar una Descripción de
Producto para un plan en el Apéndice A.
En la Figura 7.1 se ilustran los niveles de
planificación de PRINCE2.
El Plan de Proyecto se crea en el proceso del Inicio
de un Proyecto.
El Plan de la Fase de Inicio se crea en el proceso
de la Puesta en Marcha de un Proyecto y
posteriormente cada uno de los Planes de Fase se
crea en el proceso de la Gestión de los Límites de
Fase. Téngase en cuenta que, como el Plan de la
Fase de Inicio se crea antes del Plan de Proyecto,
está influenciado por el plan corporativo o del
programa (o equivalente) de la organización que
encarga el proyecto.
Los Planes del Equipo se crean en el proceso de la
Gestión de la Entrega de Productos.
Plan corporativo
o del programa
Plan de Proyecto
(Inicio) (Entrega)
Plan de la Fase Planes de Fase
Planes de Equipo
Figura 7.1 Niveles de planificación de PRINCE2
Por último, el único plan que queda de PRINCE2 es
el Plan de Revisión de Beneficios (véase el Capítulo
4 para más información). Este cubre actividades
durante y después del proyecto y, por lo tanto,
podría ser parte de un plan corporativo o de
programa. El Plan de Revisión de Beneficios abarca
los niveles corporativo, de proyecto y de fase.
7.2.4 El Plan de Proyecto
El Plan de Proyecto proporciona una explicación de
cómo y cuándo se tienen que lograr las metas de
rendimiento de tiempo, coste, alcance y calidad del
proyecto, mostrando los productos, actividades y
recursos principales requeridos para el proyecto. El
Plan de Proyecto:
■■ Proporciona al Business Case costes y
calendarios del proyecto planificados e
identifica los puntos de control importantes,
como por ejemplo, fases de gestión e hitos
■■ Es utilizado por la Junta de Proyecto como
baseline con la que hacer un seguimiento del
progreso del proyecto fase por fase
■■ Está en línea con el plan de la gerencia
corporativa o del programa.
7.2.5 Planes de Fase
Se requiere un Plan de la Fase para cada fase
de gestión. El Plan de la Fase es similar al Plan
de Proyecto en cuanto al contenido, pero se
desglosará cada elemento al nivel de detalle
necesario para constituir una base adecuada para
el control diario por parte del Project Manager.
Planes de Excepción
según sea necesario

Cada Plan de la Fase para la siguiente fase de
gestión se elabora cuando se acerca el final de la
fase de gestión actual. Este enfoque permite que el
Plan de la Fase:
■■ Se elabore a poca distancia temporal de los
eventos planificados
■■ Exista durante mucho menos tiempo que el
Plan de Proyecto (y, por lo tanto, se resuelve la
cuestión del horizonte de planificación)
■■ Sea elaborado con conocimiento del
rendimiento de las fases de gestión anteriores.
Véase el Capítulo 10 para más información sobre
cómo dividir un proyecto en fases de gestión.
7.2.6 Planes del Equipo
Un Plan del Equipo es elaborado por un Team
Manager para facilitar la ejecución de uno o
más Paquetes de Trabajo. Los Planes del Equipo
son opcionales; su necesidad y su cantidad serán
determinadas por el tamaño y la complejidad del
proyecto y por la cantidad de recursos implicados.
PRINCE2 no estipula el formato o composición
de un Plan del Equipo. Puede existir más de un
equipo en un proyecto y cada equipo puede
Planes | 71
provenir de organizaciones diferentes que usen
normas de gestión de proyectos distintas (no
necesariamente PRINCE2). En algunos contextos de
cliente/proveedor podría incluso ser inapropiado
que el Project Manager vea la información del
Plan del Equipo de un proveedor; en su lugar, se
proporcionaría información abreviada suficiente
para que el Project Manager pueda ejercer control.
Por lo tanto, el grado de formalidad del Plan del
Equipo podría variar desde un simple anexo al
Paquete de Trabajo hasta un plan completo con un
estilo similar al de un Plan de la Fase.
El/Los Team Manager(s) puede(n) crear sus Planes
del Equipo paralelamente a la creación del Plan de
la Fase por parte del Project Manager para la fase
de gestión.
7.2.7 Planes de Excepción
Un Plan de Excepción es un plan preparado para
que el nivel de gestión apropiado muestre las
acciones necesarias para recuperarse del efecto de
una desviación respecto de las tolerancias. Si se
aprueba, el Plan de Excepción sustituirá al plan que
se encuentra en estado de excepción y se convertirá
72 | Planes

en la nueva versión baseline del Plan de Proyecto o
del Plan de la Fase actual, según corresponda.
Si se va a sustituir un Plan de la Fase, se necesita la
aprobación de la Junta de Proyecto. Si la excepción
excede los niveles de autoridad de la Junta de
Proyecto, será necesario remitir la sustitución de
un Plan de Proyecto a la gerencia corporativa o del
programa.
Un Plan de Excepción se prepara con el mismo
nivel de detalle que el plan al que sustituye. Parte
de la situación real del plan actual y prosigue
hasta el final de ese plan. No se crean Planes de
Excepción para Paquetes de Trabajo. Si un Team
Manager prevé que el Paquete de Trabajo asignado
puede exceder las tolerancias, lo notificará al
Project Manager planteando una cuestión. Si la
cuestión relativa al Paquete de Trabajo se puede
resolver dentro de las tolerancias de la fase, el
Project Manager llevará a cabo rectificaciones
actualizando el Paquete de Trabajo o emitiendo
un nuevo Paquete de Trabajo (o varios) y dando las
instrucciones correspondientes al Team Manager (o
Team Managers).
Para una explicación más detallada de los tipos de
tolerancia y su uso en PRINCE2, véase el
Capítulo 10.
7.3 El enfoque de PRINCE2 hacia los
planes
7.3.1 Filosofía
La filosofía que hay detrás de la creación de los
planes en PRINCE2 es que los productos requeridos
en primer lugar se identifican y solamente
entonces se consideran las actividades necesrias,
las dependencias y los recursos que se requieren
para entregar esos productos. Esto se conoce como
planificación basada en el producto y se usa para
el Plan de Proyecto, el Plan de la Fase y, de modo
opcional, el Plan del Equipo. La Figura 7.2 muestra
los pasos necesarios para crear un plan de PRINCE2.
Durante la ejecución, puede identificarse nueva
información que requiera repetir cualquiera de
los pasos del procedimiento de planificación
(por ejemplo, al preparar el cronograma, si se
identifican actividades o dependencias adicionales).

Diseñar el plan
(7.3.2) Prerrequisito

Definir y analizar los productos

(7.3.3)
Analizar los riesgos

Identificar actividades y dependencias

(7.3.4)
(7.3.7)

Se repite para el:

Preparar estimaciones
• Plan de Proyecto
(7.3.5)
• Plan de la Fase
• Plan del Equipo
(opcional)
Preparar el cronograma
(7.3.6)

Documentar el plan
(7.3.8)

Figura 7.2 El enfoque de PRINCE2 hacia los planes

 Planes | 73

7.3.2 Prerrequisitos de la planificación –
diseñar el plan
Se tienen que tomar decisiones acerca del formato
de presentación del plan, teniendo en cuenta
los destinatarios y el uso que se hará del plan,
junto a las necesidades gráficas, las herramientas
de planificación, los métodos de estimación, los
niveles de plan y los métodos de seguimiento que
se emplearán para el proyecto. Esto incluirá la
decisión entre diagramas o textos explicativos y
dependerá, en parte, de las normas que se hayan
adoptado en el proyecto.
Cuando el proyecto forme parte de un programa,
puede que ya exista un enfoque común hacia
la planificación de proyectos. Esto puede cubrir
normas – por ejemplo, nivel de planificación – y
herramientas. Estas serán el punto de partida para
el diseño de cualquier Plan de Proyecto. Se deberá
indicar claramente cualquier variación específica
aplicada en el proyecto y obtener el acuerdo de
la gerencia del programa. También puede existir
una norma de la empresa sobre ayudas para
planificación y control, o el cliente puede estipular
el uso de un conjunto específico de herramientas.
La elección de una herramienta de planificación
puede depender de la complejidad del proyecto;
por ello, puede ser necesario posponer la elección
hasta que se conozca el grado de complejidad.
Los métodos de estimación que se tienen que
utilizar en el plan pueden afectar su diseño, por lo
que las decisiones sobre los métodos se deberían
realizar como parte del propio diseño del plan.
El uso de herramientas de planificación no es
obligatorio, pero puede ahorrar mucho tiempo si
el plan tiene que actualizarse y modificarse con
regularidad. Una buena herramienta también
puede convalidar que se han incorporado las
dependencias correctas y que éstas no han sido
deterioradas por las actualizaciones del plan.
7.3.3 Definir y analizar los productos
PRINCE2 usa la técnica conocida como planificación
basada en el producto para identificar, definir y
analizar los productos del plan, como muestra la
Figura 7.3.
La planificación basada en el producto será
probablemente iterativa. En el caso de las
Descripciones de Productos, esto significa que al
principio pueden incluir simplemente un título y
una explicación del propósito. Por lo tanto, una
nota que indicara “escribir” (en el sentido de
“escribir una Descripción de Producto”) se debería
interpretar como “comenzar a escribir y seguir
completando cuanto sea posible tan pronto como
sea apropiado”.
El formato y la presentación de la estructura
jerárquica de productos y el diagrama de flujo
de los productos se determinan por preferencia
personal. Véase el Apéndice D para consultar
ejemplos.

Redactar la Descripción del Producto del Proyecto Sólo para el

(7.3.3.1) Plan de Proyecto

Crear la estructura jerárquica de productos

(7.3.3.2)

Redactar las Descripciones de Productos Para todos los

(7.3.3.3)
niveles del plan

Crear el diagrama de flujo de los productos

(7.3.3.4)

Figura 7.3 Técnica de planificación basada en el producto

74 | Planes
Los beneficios de la planificación basada en el
producto incluyen:
■■ Identificación y documentación clara y
coherente de los productos del plan y sus
interdependencias. Esto reduce el riesgo de
que se omitan o pasen desapercibidos aspectos
importantes del alcance
■■ Eliminación de cualquier ambigüedad respecto
de las expectativas
■■ Participación de los usuarios en la especificación
de las exigencias del producto, lo que aumenta
su actitud positiva y reduce las disputas sobre la
aprobación
■■ Mejora de la comunicación: la estructura
jerárquica de productos y el diagrama de flujo
de los productos proporcionan un medio simple
y eficaz para compartir y discutir opciones
para el alcance y el enfoque que se tienen que
adoptar para el proyecto
■■ Clarificación del límite del alcance: definir
productos que están dentro y fuera del alcance
del plan y proporcionar una base para el control
de cambios, lo que evita cambios incontrolados,
el ‘aumento del alcance’ o scope creep
■■ Identificación de productos que son externos al
alcance del plan pero que son necesarios para
que pueda seguir adelante, y asignación de
éstos a otros proyectos u organizaciones
■■ Preparación del camino para la creación de
Paquetes de Trabajo para proveedores
■■ Obtención de un acuerdo claro sobre las
responsabilidades de creación, revisión y
aprobación.
7.3.3.1 Redactar la Descripción del Producto
del Proyecto
La primera tarea de la planificación basada en el
producto es redactar la Descripción del Producto
del Proyecto. Aunque el Usuario Principal es
responsable de especificar el producto del
proyecto, en la práctica el Project Manager
es quien a menudo redacta la Descripción del
Producto del Proyecto, consultando al Usuario
Principal y al Ejecutivo. Será importante dedicar
el esfuerzo necesario para que esta Descripción
de Producto sea lo más completa posible desde el
principio. Véase en el Apéndice A la composición
que se sugiere para la Descripción del Producto del
Proyecto.
7.3.3.2 Crear la estructura jerárquica de
productos
El plan se desglosa en sus productos principales,
que a continuación se desglosan también hasta
que se alcance un nivel de detalle adecuado para
el plan. Un producto de nivel bajo puede ser un
componente de solamente uno de los productos de
nivel alto. La jerarquía de productos resultante se
conoce como estructura jerárquica de productos.
Cuando se crea una estructura jerárquica de
productos, se debe considerar lo siguiente:
■■ Es habitual hacer participar a un equipo de
personas en la creación de una estructura
jerárquica de productos, que podrían
representar los diferentes intereses y los
distintos conjuntos de competencias que
participan en el resultado del plan
■■ Se acostumbra a identificar productos
organizando una sesión estructurada de
lluvia de ideas (por ejemplo, utilizando notas
adhesivas o una pizarra) para registrar cada
producto a medida que es identificado
■■ Cuando un equipo crea una estructura
jerárquica de productos, es probable que
tenga lugar una discusión sobre el modo de
estructurar los productos. Por ejemplo, si el
resultado del plan es un sistema de contabilidad
informatizado, los usuarios podrían querer que
el sistema se divida en Acreedores, Deudores,
Libro Mayor, etc. Los proveedores, sin embargo,
podrían preferir Pantallas, Informes, Bases
de Datos, etc. Ninguna de las estructuras es
incorrecta, pero el equipo de gestión del
proyecto debe alcanzar un consenso sobre qué
enfoque se utilizará en la estructura jerárquica
de productos (y por lo tanto, en el plan)
■■ Es útil identificar productos externos requeridos
por el plan. Los productos externos ya existen
o están siendo creados o actualizados fuera
del alcance del plan y son requeridos para
crear uno o más de los productos del plan.
Por ejemplo, un proyecto de contratación
pública mostraría las respuestas a la licitación
por parte de los licitadores como productos
externos. El Project Manager no es responsable
de la creación de los productos externos, ya
que éstos serán suministrados por alguien
externo al equipo de gestión del proyecto.
Para cada producto externo debería existir una
anotación correspondiente en el Registro de

Riesgos que especifique la amenaza para el
plan si el producto sufre retrasos o si no cumple
con la requerida especificación. Se debería
considerar si los productos externos requieren
Descripciones de Productos para disminuir
las posibilidades de que no aporten lo que se
espera de ellos
■■ Cuando se usa la planificación basada en
el producto, es importante considerar si
se incluyen diferentes condiciones de un
producto en particular. Un ejemplo de posibles
condiciones del producto es “maquinaria
desmontada, maquinaria desplazada y
maquinaria reensamblada”. Podría ser
apropiado identificar las diferentes condiciones
como productos diferentes, de modo que cada
condición requeriría su propia Descripción
de Producto con criterios de calidad y
controles de calidad distintos. Esto puede ser
particularmente útil cuando la responsabilidad
de crear cada condición pasará de un equipo a
otro. La otra posibilidad podría ser utilizar una
sola Descripción de Producto con un conjunto
de criterios de calidad que el producto tiene
que cumplir para obtener la aprobación para
cada condición
■■ Para la presentación de la estructura jerárquica
de productos, se tendrá que tener en cuenta el
uso de distintas formas, estilos o colores para
los diferentes tipos de producto. Por ejemplo,
en una estructura jerárquica de productos
podrían utilizarse rectángulos para representar
la mayoría de tipos de producto, pero puede
ser útil usar formas diferentes como elipses o
círculos para distinguir los productos externos.
Podrían utilizarse colores para indicar qué
equipo es responsable del producto o en qué
fase se creará el producto
■■ Si el proyecto se divide en varias fases, los
productos para cada fase se extraen de la
estructura jerárquica de productos de proyecto
para formar la estructura jerárquica de
productos de la fase. Estos pueden ampliarse
para incluir más niveles de detalle y se
pueden añadir “productos adicionales” para
proporcionar el nivel de detalle requerido para
el Plan de la Fase. Se debe prestar atención para
utilizar en los diagramas del Plan de la Fase los
mismos nombres que se utilizaron en el Plan
de Proyecto. La creación de diagramas del Plan
de la Fase puede dar lugar a reconsideraciones
que requieran hacer modificaciones adicionales
Planes | 75
en los diagramas del Plan de Proyecto para
conservar la coherencia
■■ En algunos casos, el modelo de ciclo de vida
de la organización puede tener una estructura
jerárquica de productos y un diagrama de
flujo de los productos predeterminados para
tipos de proyecto comunes y una biblioteca
de Descripciones de Productos preliminares
para productos comunes. En esos casos, no
se deberían eludir los pasos de la técnica de
planificación basada en el producto de PRINCE2,
sino que ésta se debería utilizar para verificar
si el material de la biblioteca correspondiente
está completo. Como cada proyecto es único,
pueden existir exigencias adicionales para los
productos de este proyecto o diferencias sutiles
en los criterios de calidad; las sedes pueden ser
diferentes, o las personas y responsabilidades
implicadas pueden ser distintas. Además, los
modelos de ciclo de vida a menudo abordan un
solo aspecto del alcance de un proyecto.
7.3.3.3 Redactar las Descripciones de
Productos
Se requiere una Descripción de Producto para
cada producto identificado. Cuando se crea una
Descripción de Producto, se debe considerar lo
siguiente:
■■ Las Descripciones de Productos deberían
ser redactadas tan pronto como sea posible
tras haberse identificado la necesidad de
un producto. Al principio, éstas pueden
ser solamente “esqueletos” con poca más
información que el título y el identificador. Se
perfeccionarán y modificarán a medida que se
comprende mejor el producto y se llevan a cabo
los pasos de planificación posteriores
■■ Se debería crear la versión baseline de una
Descripción de Producto cuando se crea la
versión baseline del plan que incluye ese
producto. Si más adelante se modifica el
producto, la Descripción de Producto también
debe ser sometida a control de cambios
■■ Aunque la responsabilidad de redactar
Descripciones de Productos corresponde
oficialmente al Project Manager o al Team
Manager, resulta prudente hacer participar
a representantes del área que tengan
conocimientos sobre el producto y a aquéllos
que usarán el producto en cuestión. Sin duda,
76 | Planes

se debería consultar a éstos últimos cuando se Cuando se crea un diagrama de flujo de los
definan los criterios de calidad para el producto productos, se debe considerar lo siguiente:
■■ Las Descripciones de Productos que tengan ■■ Aunque el Project Manager (o el Team
éxito se pueden reutilizar para otros proyectos Manager) es responsable de la creación
dentro de ese programa u organización. del diagrama de flujo de los productos,
Para que esto ocurra, se necesitará crear una sería razonable hacer participar a quienes
biblioteca de Descripciones de Productos desarrollarán o contribuirán a los productos
para su reutilización y también se tendrá incluidos en el plan
que implementar un mecanismo para el
■■ En vez de preparar el diagrama de flujo de
almacenamiento de las Descripciones de
los productos después de haberse elaborado
Productos en la biblioteca. El Project Manager
la estructura jerárquica de productos, algunos
debería, por lo tanto, remitirse a la biblioteca
planificadores prefieren crear el diagrama
para ver si alguna de sus Descripciones de
de flujo de los productos paralelamente a la
Productos resulta adecuada para su reutilización
estructura jerárquica de productos
y/o modificación para el proyecto
■■ Un diagrama de flujo de los productos necesita
■■ Si ya existe una especificación de exigencias
muy pocos símbolos. Se identifica cada
detallada para un producto, ésta se puede
producto que se deba desarrollar dentro del
utilizar para sustituir a la Descripción de
plan en cuestión (por ejemplo, se puede escribir
Producto, siempre que la especificación de
dentro de un rectángulo) y se muestra el orden
exigencias cubra los componentes y cumpla
en que se tienen que crear (por ejemplo, los
con los criterios de calidad esperados de una
rectángulos pueden conectarse con flechas).
Descripción de Producto. En caso contrario,
Cualquier producto que ya exista o que proceda
se debería crear una Descripción de Producto
de trabajo fuera del alcance del plan debería
que haga referencia, cuando corresponda, al
estar claramente identificado como producto
contenido de la especificación de exigencias
externo (por ejemplo, se pueden escribir dentro
■■ Para un proyecto pequeño, puede que de una figura con otra forma, como una elipse)
solamente sea necesario redactar la Descripción
■■ Podría ser útil añadir un punto de partida en
del Producto del Proyecto
el diagrama de flujo de los productos al que
■■ Los criterios de calidad, que tienen el objetivo estén conectados todos los puntos de entrada.
de distinguir un producto aceptable de uno Siempre existe una salida en un diagrama de
inaceptable, requieren ser considerados con flujo de los productos pero, cuando existen
atención. Una forma de poner a prueba los muchas entradas, ese tipo de marcador de
criterios de calidad es planteando la siguiente lugar impide que se pasen por alto. El símbolo
pregunta: ¿cómo distinguiré si el trabajo se convierte en el precedente de todos los
para este producto ha terminado o si se ha puntos de entrada y sería el único símbolo en
sencillamente estancado? un diagrama de flujo de los productos que no
7.3.3.4 Crear el diagrama de flujo de los estaría en la estructura jerárquica de productos.
productos
Se necesita crear un diagrama de flujo de los
productos para identificar y definir la secuencia en
la que se desarrollarán los productos del plan y las
dependencias entre éstos.
El diagrama de flujo de los productos también
identifica dependencias en cualquier producto
fuera del alcance del plan. Esto conduce de forma
natural a la consideración de las actividades
requeridas y proporciona la información para otras
técnicas de planificación, como la estimación y la
preparación del cronograma.

7.3.4 Identificar actividades y
dependencias
7.3.4.1 Actividades
Simplemente identificar productos podría ser
insuficiente para la preparación del cronograma y
para el control. Se necesita identificar las actividades
requeridas para crear o modificar cada uno de los
productos planificados, para ofrecer una imagen más
completa de la carga de trabajo del plan.
Existen varias maneras de identificar actividades,
incluyendo:
■■ Elaborar por separado una lista de las
actividades, pero aún así usando el diagrama
de flujo de los productos como la fuente de
información
■■ Tomar los productos de la estructura jerárquica
de productos y crear una estructura jerárquica
del trabajo para definir las actividades
requeridas.
Las actividades deberían incluir actividades de
gestión y de comprobación de calidad, así como
las actividades necesarias para desarrollar los
productos especializados. Las actividades deberían
incluir cualquier actividad que sea necesaria para
interactuar con partes externas - por ejemplo,
obtener un producto de una fuente externa o
convertir productos externos en algo que el plan
requiere.
Se debe evitar una proliferación de actividades más
allá del nivel de detalle apropiado para el nivel
del plan. Ante la duda, se debe optar por lo más
simple.
7.3.4.2 Dependencias
También se deberían identificar las dependencias
que puedan existir entre actividades (y productos).
Existen dos tipos de dependencia: interna y
externa. Un ejemplo de dependencia interna sería
que la actividad C no pueda comenzar hasta que
las actividades A y B hayan sido completadas. Los
siguientes pueden ser ejemplos de dependencias
externas:
■■ La entrega, por parte de otro proyecto, de un
producto requerido por este proyecto
■■ La entrega de una orden de compra por parte
del usuario
■■ Una decisión de la gerencia del programa.
Planes | 77
Ejemplos de técnicas de estimación
■■ Estimación descendente Cuando se ha
alcanzado una estimación general para el plan
(utilizando cualquier medio), ésta se puede
subdividir a través de los distintos niveles
de la estructura jerárquica de productos.
Por ejemplo, atendiendo a datos históricos,
el desarrollo podría ser un 50% del total y
las pruebas podrían ser un 25%. Se podrían
subdividir el desarrollo y las pruebas en sus
distintos componentes y asignar el esfuerzo
proporcionalmente
■■ Estimación ascendente Cada trabajo
individual se estima en sí mismo. A
continuación, se suman los resultados para
identificar los esfuerzos estimados para las
distintas actividades a nivel resumido y para el
plan en general
■■ Enfoque descendente y ascendente Se
calcula una estimación general para el plan.
A continuación se calculan estimaciones
individuales, o se extraen de planes
anteriores, para representar la importancia
relativa de las tareas. Entonces, la estimación
general se asigna proporcionalmente a
través de las distintas tareas a nivel resumido
y a nivel detallado utilizando las cifras
ascendentes como cálculos proporcionales
■■ Estimación comparativa Existen muchos datos
sobre el esfuerzo requerido y la duración de
elementos de trabajo concretos. A lo largo del
tiempo, una organización puede organizar
sus propios datos históricos relativos a los
proyectos que ha llevado a cabo (experiencia
previa o lecciones aprendidas). Si existen esos
datos, puede ser útil remitirse a ellos para
identificar proyectos similares y aplicar los
datos a las estimaciones
■■ Estimación paramétrica Se basan las
estimaciones en datos medidos/empíricos
siempre que sea posible (por ejemplo,
existen modelos de estimación en el sector
de la construcción que predicen materiales,
esfuerzo y duración basándose en la
especificación de un edificio)
■■ Estimación de punto único El uso de una
muestra de datos para calcular un único valor
que servirá como el “mejor pronóstico” para
la duración de una actividad
78 | Planes
■■ Estimación de tres puntos Se pregunta
a uno o varios recursos que tengan las
competencias apropiadas cuáles son sus
estimaciones para el mejor de los casos,
el peor y el más probable. El valor que el
Project Manager debería escoger es la media
ponderada de estas tres estimaciones
■■ Técnica Delphi Esta se basa en obtener
aportes de un grupo de personas para
generar ideas y resolver problemas, sin
la necesidad de una participación cara a
cara. Utiliza una serie de cuestionarios,
intercalados con resúmenes informativos
e información obtenida de respuestas
anteriores, para conseguir una estimación.
7.3.5 Preparar estimaciones
Se debe tomar una decisión sobre cuánto tiempo
y recursos son necesarios para llevar a cabo un
trabajo con un nivel de rendimiento aceptable
mediante:
■■ La identificación del tipo de recurso requerido.
Pueden ser necesarias competencias
específicas dependiendo del tipo de plan y su
complejidad. Los requerimientos pueden incluir
recursos no humanos, como equipamientos,
desplazamientos o dinero
■■ La estimación del esfuerzo necesario para cada
una de las actividades, clasificadas por tipo de
recurso. En este momento, las estimaciones
serán aproximadas y, por lo tanto, provisionales.
No se puede garantizar que las estimaciones sean
precisas pero, cuando se aplican, proporcionan una
idea del coste y tiempo totales requeridos para
completar el plan. Las estimaciones cambiarán
inevitablemente a medida que se descubre más
información sobre el proyecto.
Se debería cuestionar siempre las estimaciones, ya
que el mismo trabajo, en las mismas condiciones,
puede ser estimado de manera diferente por varios
estimadores o incluso por el mismo estimador en
momentos distintos.
Reglas básicas para la estimación
Muchos libros y paquetes de software incluyen
algunas reglas básicas para ayudar a que se
obtengan estimaciones precisas y realistas.
Estos son algunos ejemplos de esas reglas de
planificación:
■■ Asuma que los recursos solamente serán
productivos, por ejemplo, un 80% del
tiempo
■■ Los recursos que trabajan en varios
proyectos necesitan más tiempo para
completar tareas debido al tiempo perdido
al pasar de uno a otro
■■ Las personas son generalmente optimistas
y suelen subesestimar cuánto durarán las
tareas
■■ Haga uso de las experiencias de otras
personas y de la suya propia
■■ Asegúrese de que la persona responsable de
crear el producto sea también responsable
de preparar las estimaciones de esfuerzo
■■ Incluya siempre un margen para la
resolución de problemas, reuniones y otros
eventos inesperados
■■ Calcule el coste de cada actividad, en vez
de intentar calcular el coste del plan en su
totalidad
■■ Comunique al usuario o usuarios cualquier
suposición, exclusión o restricción que tenga.
7.3.6 Preparar el cronograma
Un plan solamente puede mostrar definitivamente
la viabilidad de lograr sus objetivos cuando las
actividades se agrupan en un cronograma que
defina cuándo se llevará a cabo cada actividad.
Existen muchos enfoques diferentes para la
preparación del cronograma. La preparación
del cronograma se puede hacer manualmente
o utilizando una herramienta informática de
planificación y control.
7.3.6.1 Definir la secuencia de actividades
Tras haber identificado las actividades, sus
dependencias y tras haber estimado su duración
y esfuerzo, la siguiente tarea es determinar la
secuencia óptima en que se pueden llevar a cabo.
Esta es una tarea iterativa, ya que la asignación de
recursos reales puede afectar al esfuerzo y duración
estimados.
 Planes | 79

Figura 7.4 Diagrama simple de red de actividades

Las flechas muestran las dependencias

Las actividades se muestran

como recuadros La Tarea 3 no puede comenzar hasta
que se hayan completado la Tarea 1 y 2

Tarea 1 Tarea 3

Comienzo Tarea 5 Fin

Tarea 2 Tarea 4

La Tarea 4 es predecesora de
la Tarea 5 y sucesora de las Tareas 1 y 2

ES (Earliest Start) = Tiempo de inicio más temprano para la actividad

D (Duration) = Duración de la actividad
EF (Earliest Finish) = Tiempo de término más temprano para la actividad
LS (Latest Start) = Tiempo de inicio más tardío para la actividad
ES = 18 D=5 EF = 23 TF (Total Float) = Holgura total para la actividad
LF (Latest Finish) = Tiempo de término más tardío para la actividad

Tarea 4

LS = 18 TF = 0 LF = 23

La cantidad de tiempo que se puede retrasar una

Ejemplo de técnica de redes de actividades
actividad sin afectar al tiempo para completar todo
el plan se conoce como holgura (y a veces como Se puede utilizar un diagrama de red de
margen). La holgura se puede considerar como una actividades (a veces llamado diagrama
disposición dentro del plan, o bien como tiempo por flechas) para preparar un diagrama de
libre. actividades dependientes dentro de un plan.
Resulta útil para un Project Manager identificar
Por ruta crítica, se entiende una secuencia de
la secuencia más eficaz de eventos necesarios
actividades en el diagrama que tiene margen
para completar cualquier plan, y permite crear
igual a cero. Por lo tanto, si alguna actividad en la
un cronograma realista.
ruta críticatermina tarde, todo el plan terminará
tarde (por ejemplo, en la Figura 7.4, si la tarea El diagrama de red de actividades muestra las
4 se retrasa, la finalización del plan también se interdependencias de las actividades mediante
retrasará). el uso de cuadros y flechas. Las flechas que
apuntan a un cuadro con una actividad
La identificación de la ruta crítica de un plan
proceden de sus actividades precedentes,
permite al Project Manager hacer un seguimiento
que se deben completar antes de que pueda
de aquellas actividades que:
comenzar la actividad. Las flechas que salen
■■ Se deben completar a tiempo para que la de un cuadro con una actividad apuntan hacia
totalidad del plan sea completado cumpliendo las actividades posteriores, y que no pueden
con el cronograma comenzar hasta que haya terminado, por lo
■■ Se pueden retrasar durante un tiempo si se menos, esa actividad. En la Figura 7.4 se muestra
necesita reasignar recursos para recuperar un diagrama de red de actividades.
tiempo en las actividades ya retrasadas.
80 | Planes
7.3.6.2 Evaluar la disponibilidad de recursos
Se debería determinar la cantidad de personas que
estarán disponibles para hacer el trabajo (o el coste
de obtener recursos). Se debería anotar cualquier
dato concreto (por ejemplo, nombres, niveles de
experiencia, porcentaje de disponibilidad, fechas
de disponibilidad).
7.3.6.3 Asignar recursos
El uso de la disponibilidad de recursos y de la
información de la secuencia de actividad permite al
Project Manager asignar recursos a las actividades.
El resultado será un cronograma que muestra
la carga de trabajo de cada persona y el uso de
recursos no humanos.
Un enfoque útil es asignar primero recursos a
aquellas actividades con holgura igual a cero
(que por definición están en la ruta crítica). Las
actividades con mayor holgura tienen la menor
prioridad a la hora de asignar recursos.
Es importante que se definan los propietarios de las
tareas. Si una tarea ha de ser completada por un
grupo, se debería pedir a una persona del grupo que
sea responsable frente al grupo respecto de esa tarea.
Si alguno de los propietarios de tareas no participa
en la creación del cronograma, asegúrese de que
primero se les consulta acerca de su disponibilidad
y su disposición para ser propietarios de la tarea.
No se debería dar por sentado que se hará
automáticamente el trabajo al poner sus nombres
en un plan o cronograma. Será importante
colaborar, comunicarse y hacer un seguimiento con
el propietario de cada tarea para asegurarse de
que esté claro lo que significa completar la tarea.
Cuando se asignan recursos, es importante volver a
comprobar la ruta crítica, ya que la asignación de
recursos reales puede ser más o menos productiva
que la suposición que se hizo al calcular el esfuerzo
y la duración de la actividad.
7.3.6.4 Nivelar el uso de recursos
La primera asignación de recursos puede conducir
a un uso desequilibrado de los recursos o a una
sobreutilización de algunos recursos. Por lo tanto,
puede ser necesario reorganizar los recursos; esto
se conoce como nivelar.
Se pueden reasignar actividades o se puede
cambiar sus fechas de comienzo y duraciones,
dentro del margen disponible.
El resultado final es un cronograma definitivo en
el que todas las actividades están asignadas y la
utilización de recursos es igual a la disponibilidad
de recursos.
La técnica de cadena crítica
El método de planificación de cadena crítica
pone mayor énfasis en los recursos requeridos
para ejecutar el plan y en su disponibilidad.
Esto lo diferencia de los métodos tradicionales,
que hacen énfasis en el orden de las tareas y
una preparación rígida del cronograma. Una
red de cadena crítica tenderá a mantener un
equilibrio en la carga de trabajo de los recursos,
pero requerirá que sean flexibles en sus tiempos
de comienzo y que cambien rápidamente entre
tareas y cadenas de tareas para mantener la
totalidad del plan sin retrasos respecto del
cronograma.
7.3.6.5 Acordar puntos de control
El borrador del cronograma permite que los
puntos de control sean confirmados por la Junta de
Proyecto.
Las actividades relacionadas con el final de una
fase de gestión (por ejemplo, preparar el Informe
al Final de Fase y el Plan de la Fase siguiente)
deberían ser añadidas a la red de actividades y el
cronograma debería ser revisado.
Un error habitual a la hora de crear un cronograma
es no incluir el tiempo necesario para las
aprobaciones de los productos o releases.
7.3.6.6 Definir hitos
Un hito es un evento en un cronograma que
marca la terminación de actividades principales.
Estas podrían ser la terminación de un Paquete de
Trabajo, una fase técnica o una fase de gestión. En
un entorno comercial, el hecho de alcanzar un hito
puede ser el desencadenante para un pago a un
proveedor.
La división del plan en intervalos asociados con
un hito permite al Project Manager tener una
indicación temprana de cuestiones asociadas con el
propio cronograma y también una mejor idea de
las actividades cuya terminación es crucial para la
línea de tiempo del plan.
Aunque no existe una cantidad “correcta” de hitos
o una duración “correcta” entre ellos, pierden

su utilidad si existen demasiados o muy pocos.
Debería haber muchos menos hitos que productos
a entregar o Paquetes de Trabajo, pero debería
haber suficientes hitos en los intervalos más
significativos para poder determinar si el plan está
avanzando según lo esperado o no.
7.3.6.7 Calcular las exigencias de recursos y
los costes totales
Se pueden tabular las exigencias de recursos y se
puede calcular el coste de los recursos y otros costes
para crear el presupuesto del plan.
El presupuesto debería incluir:
■■ Costes de las actividades para desarrollar y
verificar los productos especializados y el coste
de las actividades de gestión del proyecto
■■ Presupuesto para riesgos (véase el Capítulo 8)
■■ Presupuesto para cambios (véase el Capítulo 9)
■■ Tolerancias de coste.
El uso de presupuestos para riesgos y presupuestos
para cambios es opcional.
7.3.6.8 Presentar el cronograma
La mejor forma de presentar un cronograma es
gráficamente. La elección del formato dependerá
de la escala y complejidad del plan y de las
necesidades de las personas que lo recibirán. La
mayoría de las herramientas de planificación
ofrecerá distintas opciones de formato
Ejemplos de formatos de presentación para el
cronograma
Diagramas de Gantt
Un diagrama de Gantt es una representación
gráfica de la duración de las tareas con la
progresión del tiempo. Permite al Project
Manager:
■■ Evaluar cuánto debería durar un plan
■■ Establecer el orden en el que se tienen que
llevar a cabo las tareas
■■ Gestionar las dependencias entre tareas
■■ Ver qué se debería haber logrado en un
momento determinado
■■ Ver cómo las acciones correctoras pueden
hacer regresar al plan a su curso.
Planes | 81
Hojas de cálculo
Es posible crear una lista de tareas en sentido
vertical en la hoja de cálculo y una línea del
tiempo en sentido horizontal. A continuación
se colorean las celdas para representar en qué
momentos de la línea del tiempo ocurrirán
las tareas y el progreso hasta la fecha. Para
proyectos simples en los que no es probable
que la línea del tiempo cambie, ésta puede
ser una opción adecuada. Para proyectos
grandes o complejos, la línea del tiempo puede
cambiar con frecuencia. Esto supone que el
Project Manager puede tener que dedicar una
cantidad de tiempo considerable a modificar
el cronograma descuidando las tareas diarias
necesarias para gestionar el proyecto.
Lista de productos
Una lista de productos es una lista de los
productos principales de un plan y sus fechas
clave de entrega. En el esquema de Descripción
de Producto para un plan del Apéndice A se
puede ver un ejemplo de lista de productos.
Diagrama de ruta crítica
Un diagrama de ruta crítica pone de manifiesto
aquellas tareas que no pueden retrasarse sin
hacer que el plan se retrase y aquellas tareas
que se pueden retrasar sin afectar a la fecha de
finalización del plan. Ayuda al seguimiento y a
la comunicación.
7.3.7 Analizar los riesgos
Esta actividad de planificación tendrá lugar
normalmente en paralelo con los otros pasos,
ya que pueden identificarse riesgos en cualquier
momento de la creación o revisión de un plan.
Cada recurso y actividad, y toda la información
de planificación, deberían ser examinados para
identificar su contenido de riesgo potencial. Todos
los riesgos identificados se deberían anotar en el
Registro de Riesgos (o en el Archivo Diario cuando
se planifica la fase de inicio).
Una vez que ha sido creado el plan, se debería
seguir considerando que es un borrador hasta
que los riesgos inherentes al plan hayan sido
identificados y evaluados y, si procede, el plan haya
sido modificado.
82 | Planes

Véase el Capítulo 8 para más información sobre la 7.3.8 Documentar el plan

identificación y análisis de riesgos. Tras haber completado el cronograma
satisfactoriamente, el plan, sus costes, los controles
Ejemplos de riesgos en la planificación requeridos y su texto de apoyo tienen que
■■ Omisión de planes en el/los nivel(es) de consolidarse de acuerdo con el diseño del plan.
gestión apropiado(s) Se tiene que añadir texto para explicar el plan,
■■ La incorporación al plan de muchos las restricciones que pueda tener, dependencias
recursos al mismo tiempo puede ralentizar externas, suposiciones realizadas, cualquier
el progreso y causar cuestiones de seguimiento y control requeridos, los riesgos
comunicación (dibujar una curva en forma de identificados y las respuestas que requieren.
S para el perfil de los recursos a lo largo del
tiempo puede identificar esto; se deberían Es una buena práctica que los planes sean tan
evitar las curvas bruscas) simples como resulte apropiado. Considere el uso
de diagramas esquemáticos si el plan se tiene que
■■ El plan incluye recursos sin nombrar,
presentar a la Junta de Proyecto.
haciendo que la productividad del recurso
real difiera de la productividad estimada en Puede ser útil tener un formato de plan para su
el plan presentación en momentos en que se solicite una
■■ El plan contiene una proporción alta de aprobación y un formato más detallado para el
dependencias externas control diario. Considere también los diferentes
■■ El plan usa proveedores no probados o niveles de presentación del plan para los diferentes
depende de nuevas tecnologías niveles de destinatario. La mayoría de paquetes de
■■ Existe una alta proporción de actividades en software de planificación ofrecen esas opciones.
la ruta crítica – un retraso en cualquiera de Véase en el Apéndice A la composición que se
ellas retrasará el plan sugiere para un plan.
■■ El plan no prevé suficientes puntos de
decisión sobre gestión, como por ejemplo
límites de fase
■■ No hay mucho margen en el plan (la creación
de un histograma que muestre las distintas
actividades por cantidad de margen es una
manera útil de identificar este riesgo)
■■ Se tiene que completar una gran cantidad de
productos al mismo tiempo
■■ El plan tiene restricciones temporales
derivadas de plazos fiscales (por ejemplo,
el presupuesto no se puede transferir de
este año fiscal al siguiente) o de plazos de
calendario (por ejemplo, los proyectos del
llamado efecto 2000 tenían restricciones de
calendario)
■■ El cronograma muestra que es probable que
muchas rutas que transcurren muy próximas
a la ruta crítica pasen a ser críticas si hay una
pequeña desviación.
 Planes | 83

7.4 Responsabilidades
La Tabla 7.1 resume las responsabilidades relacionadas con la temática de Planes. Véase el Apéndice C para
más información sobre los roles del equipo de gestión del proyecto y sus responsabilidades asociadas.

Tabla 7.1 Responsabilidades relacionadas con la temática de Planes

Rol Responsabilidades
Gerencia corporativa o del Establecer las tolerancias del proyecto y documentarlas en el mandato de proyecto.
programa
Aprobar Planes de Excepción cuando se prevea que se van a exceder las tolerancias a nivel
de proyecto.
Proporcionar las normas de planificación de la gerencia corporativa o del programa.
Ejecutivo Aprobar el Plan de Proyecto.
Definir las tolerancias para cada fase y aprobar los Planes de Fase.
Aprobar Planes de Excepción cuando se prevea que se van a exceder las tolerancias a nivel
de fase.
Asignar recursos comerciales a los Planes de Fase (por ejemplo, financiación).
Usuario Principal Asegurarse de que los Planes de Proyecto y los Planes de Fase se mantengan coherentes
desde la perspectiva del usuario.
Asignar recursos del usuario a los Planes de Fase.
Proveedor Principal Asegurarse de que los Planes de Proyecto y los Planes de Fase se mantengan coherentes
desde la perspectiva del proveedor.
Asignar recursos del proveedor a los Planes de Fase.
Project Manager Diseñar los planes.
Preparar el Plan de Proyecto y los Planes de Fase.
Decidir cómo se aplicarán las fases técnicas y de gestión y diseñar Planes de Fase.
Ordenar que se lleven a cabo rectificaciones cuando se prevea que se van a exceder las
tolerancias a nivel de Paquete de Trabajo.
Preparar un Plan de Excepción para implementar la decisión de la gerencia corporativa, de
la gerencia del programa o de la Junta de Proyecto en respuesta a Informes de Excepción.

Team Manager Preparar Planes del Equipo.

Preparar cronogramas para cada Paquete de Trabajo.
Garantía del Proyecto Hacer un seguimiento de los cambios en el Plan del Proyecto para determinar si hay un
impacto en las necesidades de la empresa o en el Business Case del proyecto.

Hacer un seguimiento del progreso de la fase y del proyecto, comparándolo con las
tolerancias acordadas.
Apoyo al Proyecto Ayudar a la recopilación de Planes de Proyecto, Planes de Fase y Planes del Equipo.
Contribuir con conocimientos especializados (por ejemplo, herramientas de planificación).
Crear las versiones baseline, almacenar y distribuir Planes de Proyecto, Planes de Fase y
Planes del Equipo.
Riesgo 8
8 Riesgo
8.1 Propósito
El propósito de la temática de Riesgo es
identificar, evaluar y controlar la incertidumbre
y, en consecuencia, mejorar las posibilidades de
que el proyecto tenga éxito.
Tomar riesgos en los proyectos es inevitable, ya
que los proyectos son algo que posibilita el cambio
y el cambio supone incertidumbre y, por lo tanto,
riesgo.
La gestión del riesgo debe ser sistemática y no
basarse en la casualidad. Se trata de llevar a cabo
una identificación, evaluación y control proactivos
de los riesgos que podrían afectar a la entrega de
los objetivos del proyecto.
El proyecto debe establecer y mantener un
procedimiento de gestión del riesgo rentable. El
objetivo es fomentar una mejor toma de decisiones
mediante una buena comprensión de los riesgos –
sus causas, su probabilidad, su impacto, sus tiempos
y las opciones de respuesta a ellos.
La gestión del riesgo es una actividad continua,
que se lleva a cabo durante toda la vida del
proyecto. Sin un procedimiento de gestión del
riesgo continuo y eficaz no es posible proporcionar
la seguridad de que el proyecto sea capaz de lograr
sus objetivos ni, por consiguiente, si merece la pena
que continúe. Por ello, la gestión del riesgo eficaz
es un prerrequisito del principio de la justificación
comercial continua.
8.2 Definición de riesgo
8.2.1 ¿Qué es un riesgo?
Un riesgo es un evento o conjunto de eventos
incierto(s) que, si tuviera(n) lugar, tendría(n) un
impacto en el logro de los objetivos. 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. En
este sentido:
■■ Amenaza se utiliza para describir un evento
incierto que podría tener un impacto negativo
en los objetivos
■■ Oportunidad se utiliza para describir un evento
incierto que podría tener un impacto favorable
en los objetivos.
8.2.2 ¿Qué está en riesgo?
En el contexto de un proyecto, son los objetivos
del proyecto lo que está en riesgo. Estos incluirán
completar el proyecto cumpliendo con una serie de
metas, que normalmente abarcan tiempo, coste,
calidad, alcance, beneficios y riesgo.
Para más información sobre estas metas, véase la
sección 2.5.
8.2.3 ¿Qué es la gestión del riesgo?
La expresión “gestión del riesgo” se refiere a
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. Esto proporciona un entorno
disciplinado para una toma de decisiones proactiva.
Para que la gestión del riesgo sea eficaz, los riesgos
tienen que ser:
■■ Identificados Esto incluye considerar riesgos
que podrían afectar al logro de los objetivos
del proyecto y, a continuación, describirlos
para garantizar que exista una comprensión
uniforme de estos riesgos
■■ Evaluados Esto incluye asegurarse de que
cada riesgo pueda ser clasificado en base a su
probabilidad, impacto e inmediatez estimados,
y comprender el nivel general de riesgo
asociado al proyecto
■■ Controlados Esto incluye identificar respuestas
apropiadas a los riesgos, asignar propietarios
del riesgo y a continuación la ejecución, el
seguimiento y control de estas respuestas.
La gestión del riesgo se aplica desde las
perspectivas estratégica, operativa, del programa
y del proyecto. El enfoque hacia la gestión
del riesgo puede ser común para todas estas
perspectivas, pero los procedimientos de gestión
del riesgo deben ser adaptados a cada una de ellas.
Véase la Figura 8.1, que muestra las perspectivas
organizativas.
88 | Riesgo
Largo plazo
Estratégica
Cambio en el negocio
Programa
Medio plazo
Corto plazo
Figura 8.1 Perspectivas organizativas
8.3 El enfoque de PRINCE2 hacia el
riesgo
8.3.1 Principios de la gestión del riesgo
El enfoque de PRINCE2 hacia la gestión del riesgo
se basa en la publicación de OGC Management of
Risk: Guidance for Practitioners (TSO, 2007) y se
conoce también por sus siglas en inglés M_o_R®. La
gestión del riesgo se basa en una serie de principios
de gestión del riesgo, de los cuales los siguientes
son apropiados en el contexto de un proyecto:
■■ Comprender el contexto del proyecto
■■ Hacer participar a las partes interesadas
■■ Establecer objetivos del proyecto claros
■■ Desarrollar el enfoque de gestión del riesgo del
proyecto
■■ Informar regularmente sobre los riesgos
■■ Definir roles y responsabilidades claros
■■ Establecer una estructura de apoyo y una
cultura de apoyo para la gestión del riesgo
■■ Hacer un seguimiento de indicadores de alerta
anticipada
■■ Establecer un ciclo de revisión y procurar una
mejora continua.
Proyecto
Operacional
8.3.2 Gestión del riesgo en proyectos
Un punto de partida para todos los proyectos
será identificar si existen políticas y procesos
corporativos o del programa que se tengan que
aplicar. Esta información puede estar en forma
de política de gestión del riesgo y/o de guía del
proceso de gestión del riesgo (o documentos
similares).
■■ La política de gestión del riesgo de una
organización debe comunicar cómo se
implementará la gestión del riesgo en toda la
organización para ayudar a la materialización
de sus objetivos estratégicos. Esto incluirá
información como la propensión al riesgo (la
actitud única de una organización hacia los
riesgos, que a su vez determina la cantidad
de riesgo que considera aceptable), las
tolerancias de riesgo, los procedimientos para
la presentación de excepciones y los roles y
responsabilidades definidos de la organización
■■ La guía del proceso de gestión del riesgo de
una organización debe describir una serie de
pasos (y sus respectivas actividades) que son
necesarios para implementar la gestión del
riesgo. Esta guía debería proporcionar un

enfoque de aplicación de las mejores prácticas
que contribuirá a un método de gestión del
riesgo coherente en toda la organización.
Cuando el proyecto forma parte de un programa,
el enfoque del proyecto hacia la gestión del riesgo
vendrá determinado por la Estrategia de Gestión
del Riesgo del programa.
Una recomendación de PRINCE2 es que todos los
proyectos deben tener su propia Estrategia de
Gestión del Riesgo (que defina los procedimientos
del proyecto para la gestión del riesgo, desde la
identificación hasta la implementación) y un medio
de control, esto es, el Registro de Riesgos.
Para más información sobre los documentos de la
política de gestión del riesgo y la guía del proceso
de gestión del riesgo, véase la publicación de OGC
Management of Risk: Guidance for Practitioners
(TSO, 2007).
8.3.3 Estrategia de Gestión del Riesgo
Tras haber revisado los documentos a nivel de
organización y a nivel de programa, y antes de
abordar las actividades de gestión del riesgo,
se debe desarrollar una Estrategia de Gestión
del Riesgo para el proyecto. El propósito de
esta estrategia es describir cómo se integrará la
gestión del riesgo en las actividades de gestión del
proyecto.
Una decisión clave que se tiene que registrar
dentro de la Estrategia de Gestión del Riesgo es
la actitud de la Junta de Proyecto hacia la toma
de riesgos, que a su vez especifica la cantidad de
riesgo que considera aceptable. La información
se registra en forma de tolerancias de riesgo, que
representan los niveles de exposición que, si se
exceden, desencadenarán un Informe de Excepción
para poner la situación en conocimiento de la
Junta de Proyecto.
Véase la Descripción de Producto de una Estrategia
de Gestión del Riesgo en el Apéndice A.
8.3.4 Registro de Riesgos
El propósito del Registro de Riesgos es registrar y
mantener información sobre todas las amenazas
y oportunidades identificadas en relación al
proyecto. A cada riesgo en el Registro de Riesgos
se le asigna un identificador único, además de
información como:
■■ Quién planteó el riesgo
Riesgo | 89
■■ Cuándo se planteó
■■ La categoría de riesgo
■■ La descripción del riesgo (causa, evento de
riesgo, efecto)
■■ Probabilidad, impacto y valor esperado
■■ Proximidad
■■ Categoría de respuesta al riesgo
■■ Acciones de respuesta al riesgo
■■ Estado del riesgo
■■ Propietario del riesgo
■■ Ejecutor del riesgo.
El Apoyo al Proyecto mantendrá normalmente
el Registro de Riesgos en nombre del Project
Manager. La Estrategia de Gestión del Riesgo
describirá el procedimiento para registrar riesgos y
mantener el Registro de Riesgos.
Véase la Descripción de Producto de un Registro de
Riesgo en el Apéndice A.
Ejemplo de tolerancia de riesgo
Una gran empresa distribuidora de aparatos
eléctricos no toleraría ningún trastorno
innecesario en sus sistemas de apoyo durante el
período de mayores ventas, que abarca desde
mitad de noviembre hasta el final de enero.
Los proyectos no tienen permitido introducir
cambios en los sistemas de apoyo durante este
período. Por lo tanto, cualquier riesgo en el
Registro de Riesgos que supondría un cambio
en los sistemas de apoyo durante ese período de
mayores ventas tendría que presentarse como
excepción a la Junta de Proyecto.
8.3.5 Procedimiento de gestión del
riesgo
PRINCE2 recomienda un procedimiento de gestión
del riesgo que incluya los cinco pasos siguientes:
■■ Identificar (contexto y riesgos)
■■ Evaluar (estimar y valorar)
■■ Planificar
■■ Implementar
■■ Comunicar.
Los primeros cuatro pasos son consecutivos,
mientras que el paso de “Comunicar” va en
paralelo a los demás, porque la información
resultante de cualquiera de los otros pasos podría
tener que ser comunicada antes de terminarse
90 | Riesgo
todo el proceso. Todos los pasos son iterativos
por naturaleza, en el sentido de que cuando se
disponga de información adicional, a menudo
será necesario reconsiderar los pasos anteriores y
volverlos a realizar para lograr el resultado más
eficaz.
La Figura 8.2 muestra los elementos del
procedimiento de gestión del riesgo, que se
describen en las secciones 8.3.5.1. a 8.3.5.5.
Implementar
Identificar
Comunicar
Planificar Evaluar
Figura 8.2 El procedimiento de gestión del riesgo
8.3.5.1 Identificar
Identificar el contexto
El objetivo principal del paso de “Identificar
el contexto” es obtener información sobre el
proyecto para comprender los objetivos concretos
que están en riesgo y formular la Estrategia de
Gestión del Riesgo para el proyecto. La Estrategia
de Gestión del Riesgo describe cómo se gestionarán
los riesgos durante el proyecto. Se crea durante la
fase de inicio y después se revisa y, si es necesario,
se actualiza, al final de cada fase. La Estrategia de
Gestión del Riesgo del proyecto debería basarse en
la política corporativa de gestión del riesgo o en la
Estrategia de Gestión del Riesgo del programa.
Los siguientes elementos influirán en la Estrategia
de Gestión del Riesgo del proyecto:
■■ Expectativas de calidad del cliente
■■ La cantidad de organizaciones participantes y la
relación entre ellas
■■ Las necesidades de las partes interesadas que
participan en el proyecto
■■ La importancia, complejidad y escala del
proyecto
■■ Las suposiciones que se hayan realizado
■■ El propio entorno de la organización (por
ejemplo, exigencias legislativas o de gobierno)
■■ El enfoque de la organización hacia la gestión
del riesgo, según se describe en su política de
gestión del riesgo.
Esta información derivará del mandato de
proyecto, el Expediente del Proyecto y la
Descripción del Producto del Proyecto. La
Estrategia de Gestión del Riesgo incluirá decisiones
sobre:
■■ Procedimiento de gestión del riesgo
■■ Las herramientas y técnicas que se tienen que
usar
■■ Los testimonios documentales que se deben
mantener
■■ La presentación de informes sobre riesgos
■■ El calendario de las actividades de gestión del
riesgo
■■ Los roles y responsabilidades para el
procedimiento de gestión del riesgo
■■ Las escalas de riesgo que se deben utilizar (para
la probabilidad, impacto y proximidad)
■■ Cualquier clasificación de riesgos (y
posiblemente, la estructura jerárquica de
riesgos que se usará)
■■ Las categorías de respuesta al riesgo que se
utilizarán
■■ Los indicadores de alerta anticipada
■■ Cualquier tolerancia de riesgo
■■ Si se establecerá un presupuesto para riesgos y,
en ese caso, cómo se controlará.
Los indicadores de alerta anticipada (pertinentes
al proyecto) proporcionarán una alerta por
adelantado de que uno o más de los objetivos del
proyecto podrían estar en riesgo. Los indicadores
de alerta anticipada podrían incluir datos de
rendimiento del progreso (véase el Capítulo 10)
como:
■■ El porcentaje de Paquetes de Trabajo logrados/
no logrados a tiempo según el cronograma
■■ El porcentaje de aprobaciones logradas/no
logradas a tiempo según el cronograma
■■ El número de cuestiones planteadas (por
semana/por mes)

■■ El porcentaje de cuestiones que aún no se han
resuelto
■■ La cifra media de días que las cuestiones
permanecen sin resolverse
■■ La cifra media de defectos registrados en
inspecciones de calidad
■■ La adherencia al presupuesto (por ejemplo, si el
nivel de gasto está por encima o por debajo del
gasto planificado)
■■ La adherencia al cronograma (por ejemplo, días
de adelanto o retraso respecto del cronograma).
Otros indicadores de alerta anticipada podrían
indicar datos ajenos al proyecto como la satisfacción
del cliente, los niveles de absentismo, las tasas de
pérdida de personal, etc., si son pertinentes para el
proyecto. También es útil analizar e informar sobre
la dirección en que se mueven estos indicadores
de alerta anticipada (es decir, si están mejorando o
empeorando), ya que eso puede ser más revelador
que su valor de forma aislada.
Técnicas de identificación de riesgos
Los riesgos se pueden identificar utilizando una
serie de técnicas, como las siguientes:
■■ Lecciones de revisión Los riesgos se basan
en la incertidumbre, por lo que una de
las maneras más eficaces de reducir la
incertidumbre es revisar proyectos anteriores
que fueran similares, para ver qué amenazas y
oportunidades los afectaron
■■ Listas de riesgos Estas son listas internas de
riesgos que se han identificado o han tenido
lugar en anteriores proyectos similares. Las
listas de riesgos son una ayuda útil para
garantizar que no se pasen por alto los
riesgos identificados en proyectos anteriores
Riesgos financieros
Exceso de extensión
Riesgo de divisa
de crédito
Quiebra
Figura 8.3 Ejemplo de una estructura jerárquica de riesgos
Riesgo | 91
■■ Listas de posibles riesgos Estas son listas
de uso público que clasifican los riesgos por
tipos o áreas y son normalmente aplicables a
una amplia variedad de proyectos. Las listas
de posibles riesgos ayudan a fomentar que
se piense sobre las fuentes de riesgo en el
contexto más amplio
■■ Sesión de lluvia de ideas Esta permite
pensar en grupo, que puede ser más
productivo que pensar individualmente. Sin
embargo, es importante evitar las críticas
durante el intercambio de ideas, ya que esto
puede hacer que las personas involucradas
dejen de contribuir. Además de identificar
riesgos, las sesiones de lluvia de ideas
también se pueden usar para comprender
el punto de vista de las partes interesadas
respecto de los riesgos identificados
■■ Estructura jerárquica de riesgos Esta es
una fragmentación jerárquica del entorno
del proyecto, que se prepara para mostrar
posibles fuentes de riesgo. Cada nivel
descendente representa una definición cada
vez más detallada de las fuentes de riesgo
para el proyecto. La estructura motiva y
ayuda al equipo de gestión del proyecto
a pensar en todas las posibles fuentes de
riesgo para los objetivos. Hay muchas formas
de dividir el riesgo y podría ser útil preparar
más de una lista. Por ejemplo, una estructura
jerárquica de riesgos podría subdividirse
de acuerdo con la regla mnemotécnica
“PASTEL” (político, ambiental, sociológico,
tecnológico, económico, legal/legislativo), o
según la estructura jerárquica de productos,
o por fases, por beneficios/objetivos, etc. La
Figura 8.3 muestra una estructura jerárquica
de riesgos relativa a riesgo económico.
Estas estructuras ayudarán a identificar
propietarios del riesgo apropiados para
desarrollar respuestas
Insolvencia del cliente
Incumplimiento Incumplimiento
de pago de contrato
92 | Riesgo

Identificar riesgos La relación entre la causa, el evento y el efecto

El objetivo principal del paso de “Identificar también podría expresarse en una frase. Por
riesgos” es reconocer las amenazas y ejemplo:
oportunidades que pueden afectar a los objetivos ■■ Amenaza Como ha estado lloviendo de manera
del proyecto. abundante (causa del riesgo), existe una
PRINCE2 recomienda las siguientes acciones: amenaza de que el río que pasa por el campo
del agricultor se desborde (evento del riesgo),
■■ Registrar en el Registro de Riesgos las amenazas lo que dañaría gravemente la cosecha del
y oportunidades identificadas agricultor (efecto del riesgo)
■■ Preparar indicadores de alerta anticipada para ■■ Oportunidad Como el invierno no ha sido
hacer un seguimiento de los aspectos cruciales particularmente muy frío (causa del riesgo),
del proyecto y proporcionar información sobre existe una oportunidad de que menos gente sea
las posibles fuentes de riesgo hospitalizada por gripe (evento del riesgo), lo
■■ Comprender el punto de vista de las partes que significará que habrá menos trastornos en
interesadas respecto de los riesgos específicos las operaciones rutinarias planificadas (efecto
registrados. del riesgo).
Una manera eficaz de identificar riesgos es utilizar
un taller de trabajo de riesgos. Este consiste en Una causa de riesgo
una sesión de grupo diseñada para identificar
amenazas y oportunidades. La sesión debe ser
dirigida por alguien que sea capaz de utilizar puede provocar
Un evento de riesgo
una serie de técnicas de identificación, como las
indicadas en el ejemplo. Los talleres de trabajo
deben conducir a la identificación de una amplia
que puede afectar
variedad de riesgos y posibles propietarios del Un objetivo
riesgo.
Un aspecto importante de la identificación de
Figura 8.4 Causa, evento y efecto de riesgo
riesgos es ser capaz de expresar cada uno de ellos
de modo claro y sin ambigüedades. Una forma útil
de expresar el riesgo es considerar los siguientes
aspectos de cada riesgo:
■■ Causa del riesgo Esta debe describir la fuente
del riesgo, es decir, el evento o la situación
de la que deriva el riesgo. A menudo se hace
referencia a éstas como originadores del riesgo.
No son riesgos en sí mismas, sino los posibles
puntos desencadenantes del riesgo. Pueden ser
internas o externas al proyecto
■■ Evento del riesgo Este debe describir el área
de incertidumbre en base a la amenaza o la
oportunidad
■■ Efecto del riesgo Este debe describir el/los
impacto(s) que el riesgo tendría en los objetivos
del proyecto si se materializara el riesgo.
La relación entre causa, evento y efecto se muestra
en la Figura 8.4.

8.3.5.2 Valorar
Estimar
El objetivo principal del paso de “Estimar” es
evaluar las amenazas y las oportunidades para el
proyecto en base a su probabilidad e impacto. La
proximidad del riesgo también resultará útil para
determinar con qué rapidez es probable que se
materialice el riesgo si no se emprende ninguna
acción.
PRINCE recomienda que exista una comprensión de
lo siguiente:
■■ La probabilidad de las amenazas y
oportunidades, en el sentido de qué
probabilidad hay de que ocurran
■■ El impacto de cada amenaza y oportunidad en
base a los objetivos del proyecto. Por ejemplo,
si los objetivos se miden por tiempo y coste, el
impacto también se debe medir en unidades de
tiempo y coste
■■ La proximidad de esas amenazas y
oportunidades, teniendo en cuenta cuándo se
podrían materializar
■■ Cómo puede cambiar el impacto de las
amenazas y oportunidades a lo largo de la vida
del proyecto.
Una manera útil de resumir el conjunto de
riesgos y sus estimaciones es esquematizarlas en
un perfil de riesgo abreviado. Se puede ver un
ejemplo en la Figura 8.6. Este perfil representa
una situación en un momento específico, es decir,
una imagen instantánea del entorno de riesgo. Los
marcadores numerados de la matriz representan
identificadores de riesgo únicos utilizados
en el Registro de Riesgos en el que se basa la
información. Los riesgos por encima y a la derecha
de la línea de puntos que marca la tolerancia de
riesgo representan los que la organización no
tolerará salvo en situaciones extraordinarias. En
el caso ilustrado, el Project Manager remitiría los
riesgos 1, 3 y 4 a la Junta de Proyecto.
El perfil de riesgo abreviado también se puede
utilizar para mostrar tendencias. Por ejemplo, el
riesgo 6 podría haberse registrado previamente
como probabilidad baja, impacto alto, indicando
que la probabilidad de que ocurra está
aumentando.
Riesgo | 93
Técnicas de estimación del riesgo
Los riesgos se pueden estimar utilizando una serie
de técnicas, como las siguientes:
■■ Árboles de probabilidad Estos son
representaciones gráficas de los posibles
eventos que derivan de determinadas
circunstancias. Se puede usar un árbol de
probabilidad para predecir un resultado
final de modo cualitativo cuando se
utilizan datos históricos para estimar la
probabilidad de que ocurra cada circunstancia.
Los árboles de probabilidad ayudan a
comunicar la probabilidad de los diferentes
resultados finales posibles de un conjunto
de circunstancias a los participantes de un
proyecto o a quienes toman las decisiones
■■ Valor esperado Esta técnica cuantifica el
riesgo combinando el coste del impacto del
riesgo con la probabilidad de que ocurra el
riesgo. El valor esperado es útil cuando se
requiere una medición tangible del riesgo
para posibilitar la ordenación de riesgos
por prioridad. Por ejemplo, si el coste de un
riesgo fuera 160.000 € y la probabilidad de
que ocurra se estimara en un 25%, el valor
esperado sería de 40.000 €
■■ Análisis de Pareto Esta técnica ordena los
riesgos después de que hayan sido evaluados
para determinar el orden en el que se
deberían abordar. El análisis de Pareto se
puede utilizar para centrar los esfuerzos de la
gestión en aquellos riesgos con el potencial
de tener el mayor impacto en los objetivos del
proyecto
■■ Tabla de probabilidad-impacto Esta tabla
contiene valores de ordenación que se
pueden usar para ordenar cualitativamente
las amenazas y las oportunidades. Las
escalas de probabilidad son mediciones de
probabilidad derivadas de porcentajes y
las escalas de impacto se seleccionan para
reflejar el nivel de impacto en los objetivos
del proyecto. Los valores dentro de las
celdas de la tabla son la combinación de una
probabilidad y un impacto concretos y se
determinan multiplicando la probabilidad
por el impacto. Una tabla de probabilidad-
impacto se puede usar para proporcionar
una evaluación de la severidad de un riesgo y
permite que se ordenen los riesgos para que
el tiempo y esfuerzo de gestión se puedan
priorizar. Por ejemplo, la Junta de Proyecto
podría fijar su tolerancia de riesgo en
cualquier riesgo con un valor superior a 0,18,
y podría requerir una respuesta proactiva
para cualquier riesgo con un valor superior a
0,045, como se ilustra en el sombreado de la
Figura 8.5.
94 | Riesgo

Muy alta
0,9 71–90% 0,045 0,09 0,18 0,36 0,72

Alta
0,7 51–70% 0,035 0,07 0,14 0,28 0,56
Probabilidad

Media
0,5 31–50% 0,025 0,05 0,10 0,20 0,40

Baja
0,3 11–30% 0,015 0,03 0,06 0,12 0,24

Muy baja
0,1 hasta 10% 0,005 0,01 0,02 0,04 0,08

Muy bajo Bajo Medio Alto Muy alto

0,05 0,1 0,2 0,4 0,8

Impacto

Figura 8.5 Tabla de probabilidad-impacto

Evaluar ■■ Valor monetario esperado Esta técnica toma

El objetivo principal del paso de “Evaluar” es los valores esperados de una serie de riesgos
evaluar el efecto neto de todas las amenazas y y los suma para obtener un valor total.
Proporciona una evaluación rápida y sencilla
oportunidades identificadas en un proyecto cuando
de un grupo de riesgos para comprender su
son consideradas en conjunto. Esto permitirá que
efecto combinado. Se muestra un ejemplo en
se haga una evaluación de la severidad total de los la Tabla 8.1.
riesgos que afectan al proyecto, para determinar
si el nivel de riesgo se encuentra dentro de la
tolerancia de riesgo fijada por la Junta de Proyecto
Tabla 8.1 Ejemplo de la técnica de valor monetario
y si el proyecto tiene una justificación comercial
continua. esperado

Técnicas de evaluación del riesgo Identificador Probabilidad Impacto Valor

de riesgo (%) (€) esperado (€)
Los riesgos se pueden evaluar utilizando técnicas
como las siguientes: 1 60 20.000 12.000
2 30 13.000 3.900
■■ Modelos de riesgo Un ejemplo es el análisis
de Monte Carlo. Este modelo permite una 3 10 4.000 400
simulación de escenarios del tipo “qué 4 5 10.000 500
pasaría si”, utilizando números aleatorios Valor monetario esperado 16.800
para determinar si ocurre o no cada riesgo
dentro de un intervalo determinado. Las
simulaciones se llevan a cabo repetidamente 8.3.5.3 Planificar
para predecir el nivel “medio” de riesgo para El objetivo principal del paso de “Planificar” es
el tiempo o coste del proyecto. Los escenarios preparar respuestas de gestión concretas para
también se pueden usar para hacer un las amenazas y oportunidades identificadas,
modelo de casos extremos (por ejemplo, si
preferiblemente para eliminar o reducir las
casi todos los riesgos ocurren)
amenazas y maximizar las oportunidades. Prestar
 Riesgo | 95

Figura 8.6 Perfil de riesgo abreviado Las respuestas al riesgo no eliminan

Muy alta
Alta 2 4
Media 8 6
Baja 10
Muy baja 9 2
Prob.
Muy bajo Bajo Medio
Impacto
Línea de tolerancia del riesgo
atención al paso de Planificar garantiza, en la
medida de lo posible, que el proyecto no está
desprevenido si se materializa un riesgo.
El paso de Planificar implica identificar y evaluar
una serie de opciones para responder a amenazas
y oportunidades. Es importante que la respuesta al
riesgo sea proporcional al riesgo y que ofrezca una
buena relación entre coste y beneficio. Un factor
clave en la selección de respuestas será sopesar el
coste de implementar las respuestas frente a la
probabilidad e impacto de permitir que el riesgo
ocurra. Las respuestas seleccionadas se deben
incorporar en el plan del nivel adecuado, indicando
cualquier estrategia alternativa. Los distintos tipos
de respuestas a amenazas y oportunidades se
resumen en la Figura 8.7. Los tipos de respuesta se
explican con mayor detalle en la Tabla 8.2.
necesariamente el riesgo inherente en su
1 3 totalidad, pudiendo dejar riesgo residual. Si el
riesgo inherente era importante y la respuesta al
riesgo solamente ha tenido éxito parcialmente,
el riesgo residual puede ser considerable. Podría
ser apropiado seleccionar más de una respuesta al
riesgo.
7
En algunos casos, implementar una respuesta
al riesgo reducirá o eliminará otros riesgos
5
relacionados. También es posible que las respuestas
a los riesgos, una vez implementadas, cambien
Alto Muy alto
algún aspecto del proyecto. Por su parte, esto
puede conducir a riesgos secundarios, es decir,
riesgos que podrían ocurrir como resultado de
poner en marcha una respuesta al riesgo. Es
fundamental que estos se identifiquen, evalúen y
controlen del mismo modo que el riesgo inherente
Es aconsejable revisar lecciones de anteriores
proyectos similares cuando se planifican las
respuestas al riesgo.
Esto ayudará a identificar las distintas respuestas
disponibles y a evaluar cuál será su probable
eficacia.
También se debe considerar el efecto que las
posibles respuestas podrían tener sobre:
■■ El Plan de Proyecto, el Plan de la Fase y los
Paquetes de Trabajo
■■ El Business Case
■■ La gerencia corporativa y/o del programa.

Respuestas a amenazas Respuestas a oportunidades

Evitar Aprovechar

Reducir
(probabilidad y/o impacto)

Estrategia alternativa Incrementar

(sólo reduce el impacto)

Transferir
(sólo reduce el impacto y, a menudo,
sólo el impacto financiero)

Compartir

Aceptar Rechazar

Figura 8.7. Respuestas a amenazas y oportunidades

96 | Riesgo
Tabla 8.2 Respuestas al riesgo
Respuesta Definición
Evitar Normalmente implica cambiar algún aspecto
(amenaza) del proyecto, esto es, el alcance, la ruta de
suministro, el proveedor o la secuencia de
actividades, para que la amenaza ya no pueda
tener un impacto o ya no pueda ocurrir.
Reducir Se realizan acciones proactivas para:
(amenaza)
■■ Reducir la probabilidad de que ocurra el
evento, llevando a cabo alguna forma de
control
■■ Reducir el impacto del evento en el caso de
que ocurra.
Estrategia Se pone en práctica una estrategia alternativa
alternativa para las acciones que se realizarán para reducir
(amenaza) el impacto de la amenaza en el caso de que
ocurra el riesgo. Esta es una forma reactiva de
la respuesta de “reducir”, que no tiene impacto
sobre la probabilidad.
Transferir Un tercero asume la responsabilidad de una
(amenaza) parte del impacto económico de la amenaza.
(Por ejemplo, a través de un seguro o por medio
de las cláusulas pertinentes en un contrato.) Esta
es una forma de la respuesta de “reducir” que
solamente reduce el impacto económico de la
amenaza.
Aceptar Se toma una decisión consciente y deliberada
(amenaza) de retener la amenaza, habiendo concluido que
resulta más económico que intentar realizar
una acción de respuesta a la amenaza. Se
debe continuar haciendo un seguimiento de la
amenaza para asegurarse de que siga siendo
tolerable.
Compartir Los métodos de suministro modernos
(amenaza u normalmente conllevan un modo de compartir
oportunidad) el riesgo mediante la aplicación de una fórmula
de perjuicio/beneficio: ambas partes comparten
el beneficio (dentro de límites previamente
acordados) si el coste es menor que el coste
planificado; y comparten el perjuicio (de nuevo,
dentro de límites acordados previamente) si
se excede el coste planificado. Varios sectores
incluyen principios sobre compartir el riesgo en
sus contratos con terceros.
Aprovechar Explotar una oportunidad para garantizar que
(oportunidad) la oportunidad ocurrirá y que el impacto se
materializará. de software más nueva, lo que reduciría el
Ejemplo
Una reunión crucial podría verse amenazada
por restricciones en el tráfico aéreo, por lo
que el proyecto decide celebrar la reunión por
teleconferencia.
Para reducir la probabilidad de que los usuarios
no usen un producto, se aumenta la cantidad de
eventos de capacitación.
Para reducir el impacto en la escala de tiempo
en el caso de que un prototipo sea dañado
cuando se está transportando, se construyen dos
prototipos.
Las instalaciones para pruebas de la empresa
solamente están disponibles durante dos
semanas en agosto. Para reducir el impacto, en
caso de que el producto no esté disponible a
tiempo, existe una estrategia alternativa para
el alquiler de unas instalaciones para pruebas
alternativas (con un coste mayor).
Para reducir el impacto económico en el caso
de que un prototipo sea dañado cuando se está
transportando, se contrata un seguro.
Para reducir el impacto económico en el caso
de que un producto no esté disponible para
su lanzamiento en una feria, el contrato con el
proveedor incluye cláusulas compensatorias de
cuantía predeterminada en caso de demora.
Existe una amenaza de que un competidor
pueda lanzar un producto rival primero, lo que
afectaría a la cuota de mercado esperada para
el producto. La elección está entre acelerar el
proyecto incrementando los recursos, reducir el
alcance del producto para que se pueda terminar
antes o no hacer nada. Acelerar el proyecto
puede conducir a cuestiones de calidad del
producto; reducir el alcance puede hacer que el
producto sea menos atractivo; por ello, el riesgo
se acepta y se elige la opción de “no hacer
nada”.
El coste del proyecto podría verse afectado
negativamente debido a fluctuaciones en el
coste del combustible. El cliente y el proveedor
acuerdan compartir el coste de los incrementos
de precio o el ahorro de las reducciones de
precio por igual, desde un punto medio fijado en
el momento de acordar el contrato.
Existe un riesgo de que el proyecto se retrase.
Si se retrasa, podría implementarse una versión
mantenimiento continuo. La Junta de Proyecto
acuerda cambiar el calendario y el alcance
del proyecto, posibilitando que se compre e
implemente la versión más nueva del software.

Incrementar Se realizan acciones proactivas para:
(oportunidad)
■■ Incrementar la probabilidad de que el evento
ocurra
■■ Incrementar el impacto del evento si
ocurriese.
Rechazar Se toma una decisión consciente y deliberada
(oportunidad) de no aprovechar o incrementar la oportunidad,
al haber concluido que es más económico
no intentar una acción de respuesta a la
oportunidad. Se debe seguir haciendo un
seguimiento de la oportunidad.
8.3.5.4 Implementar
El objetivo principal del paso de “Implementar” es
garantizar que se pongan en marcha las respuestas
al riesgo planificadas, que se haga un seguimiento
de su eficacia y que se lleven a cabo rectificaciones
si las respuestas no cumplen con las expectativas.
Una parte importante del paso de Implementar es
asegurarse de que existan roles y responsabilidades
claros, asignados para apoyar al Project Manager
en la gestión de los riesgos del proyecto. En este
sentido, los principales roles son:
■■ Propietario del riesgo Una persona nombrada
que es responsable de la gestión, del
seguimiento y del control de todos los aspectos
de un riesgo determinado que le ha sido
asignado, incluyendo la implementación de
respuestas seleccionadas para hacer frente a las
amenazas o para maximizar las oportunidades
■■ Ejecutor del riesgo Una persona a quien se
asigna que lleve a cabo una o varias acciones de
respuesta al riesgo para responder a un riesgo
o conjunto de riesgos concretos. Presta apoyo y
recibe instrucciones del propietario del riesgo.
En muchos casos, es probable que el propietario
del riesgo y el ejecutor del riesgo sean la misma
persona. El propietario del riesgo debe ser la
persona más capaz de gestionar el riesgo. Se debe
evitar la asignación de demasiados riesgos a una
sola persona.
Riesgo | 97
Es posible que el producto complete las pruebas
de aceptación del usuario en un solo ciclo
de pruebas, en vez de los dos previstos en el
cronograma, permitiendo que se entregue antes
de lo previsto y antes que un producto rival de
la competencia. La Junta de Proyecto decide
hacer un ensayo de las pruebas para incrementar
la probabilidad de que el producto pase sus
primeras pruebas de aceptación del usuario, y
se prepara para la posibilidad de una fecha de
lanzamiento más cercana.
Es posible que el producto complete las pruebas
de aceptación del usuario en un solo ciclo
de pruebas, en vez de los dos previstos en el
cronograma, permitiendo que se entregue antes
de lo previsto y antes que un producto rival de
la competencia. La Junta de Proyecto decide
no aprovechar la ventaja de lanzar el producto
más pronto y conservar la fecha de lanzamiento
planificada.
Ejemplo de propietario del riesgo y de ejecutor
del riesgo
Existe un riesgo de que quiebre uno de los
principales proveedores. El director comercial
ha sido nombrado propietario del riesgo. Se
ha identificado y seleccionado una serie de
respuestas al riesgo. Una de las respuestas
al riesgo (estrategia alternativa) consiste en
identificar posibles proveedores alternativos
que tengan la capacidad de llevar a cabo los
Paquetes de Trabajo pese a ser avisados con
poco tiempo, y obtener un presupuesto de
cada uno de ellos. El Director de Compras es el
ejecutor del riesgo para esta respuesta concreta
al riesgo.
8.3.5.5 Comunicar
La comunicación es un paso que se lleva a cabo
de modo continuo. El paso de “Comunicar” debe
garantizar que la información relacionada con
las amenazas y oportunidades que afectan al
proyecto se comunique tanto dentro del proyecto
como externamente a las partes interesadas. Los
riesgos se comunican como parte de los siguientes
productos de gestión:
■■ Informes del Punto de Control
■■ Informes de Desarrollo
■■ Informes al Final de Fase
■■ Informes al Final de Proyecto
■■ Informes sobre las Lecciones.
98 | Riesgo

Se debe tener cuidado a la hora de utilizar número de riesgos grandes. Aquí es donde pueden
estos informes para comunicar riesgos a partes ser de ayuda técnicas analíticas como el análisis de
interesadas externas y se debe acudir a la Monte Carlo y herramientas de software asociadas.
Estrategia de Gestión de la Comunicación para
Como el presupuesto para riesgos es parte del
determinar el método más apropiado.
presupuesto del proyecto, podría haber una
Existen muchos otros métodos de comunicación, tendencia a tratarlo simplemente como otra
como boletines, tablones de anuncios, paneles, suma de dinero que el Project Manager puede
foros de discusión, sesiones informativas, etc., que gastar. Se debe evitar esa tendencia y procurar
se podrían considerar junto a los productos de que la Estrategia de Gestión del Riesgo defina
gestión de PRINCE2. los mecanismos de control de este presupuesto y
acceso a éste. A medida que avanza el proyecto,
Para que la gestión del riesgo sea eficaz se debe
algunos de los riesgos previamente identificados
tener en cuenta y abordar una serie de aspectos de
ocurrirán y otros no. Podrían identificarse nuevos
la comunicación:
riesgos durante la vida del proyecto, para los cuales
■■ La exposición al riesgo de un proyecto nunca no se habrán incluido costes de las respuestas
es estática: una comunicación eficaz es dentro del presupuesto para riesgos. Siempre
fundamental para la identificación de nuevos resulta prudente establecer un presupuesto para
riesgos o cambios en los riesgos existentes. Esto riesgos que cubra los riesgos conocidos (tal y como
depende del mantenimiento de una buena se hayan identificado) y que prevea la posibilidad
red de comunicaciones, incluyendo fuentes de riesgos desconocidos (que aún están por
de información y contactos pertinentes, para identificar).
facilitar la identificación de cambios que
puedan afectar a la exposición al riesgo total
8.4 Responsabilidades
del proyecto
■■ Una gestión del riesgo eficaz depende de la La Tabla 8.3 resume las responsabilidades
participación que, a su vez, depende de una relacionadas con la temática de Riesgo. Véase
comunicación eficaz. el Apéndice C para más información sobre los
roles del equipo de gestión del proyecto y sus
responsabilidades asociadas.
8.3.6 Presupuesto para riesgos
Un presupuesto para riesgos, en caso de utilizarse,
consiste en una suma de dinero incluida dentro
del presupuesto del proyecto y reservada para
financiar respuestas de gestión específicas para
las amenazas y oportunidades del proyecto
(por ejemplo, para cubrir los costes de cualquier
estrategia alternativa que se tuviera que
implementar).
Para determinar un presupuesto para riesgos para
el proyecto, se necesita un enfoque económico
de la gestión del riesgo. Cada riesgo debe
necesariamente ser analizado en su totalidad para
determinar los costes del impacto, los costes de las
respuestas y la probabilidad. La suma de los costes
(de las respuestas y del impacto), ponderada con
la probabilidad de cada riesgo, genera el valor
monetario previsto para el conjunto de riesgos.
El valor monetario previsto se puede utilizar
para determinar un presupuesto para riesgos. La
suposición es que se prevé usar el presupuesto de
riesgos durante el proyecto. Se tiene que tener
cuidado de que la suma de los costes tenidos en
cuenta no se vea desvirtuada por un pequeño
 Riesgo | 99

Tabla 8.3 Responsabilidades relacionadas con la temática del Riesgo

Rol Responsabilidades
Gerencia corporativa o del Proporcionar la política de gestión del riesgo y la guía del proceso de gestión del riesgo
programa corporativas (o documentos similares).
Ejecutivo Ser responsable de todos los aspectos de la gestión del riesgo y, en particular, garantizar
que exista una Estrategia de Gestión del Riesgo.
Asegurarse de que se identifiquen, evalúen y controlen los riesgos asociados al Business
Case.
Presentar riesgos como excepciones a la gerencia corporativa o del programa, cuando
sea necesario.
Usuario Principal Asegurarse de que se identifiquen, evalúen y controlen los riesgos para los usuarios
(como el impacto sobre los beneficios, el funcionamiento y el mantenimiento).
Proveedor Principal Asegurarse de que se identifiquen, evalúen y controlen los riesgos relacionados con
aspectos que afectan a los proveedores (como la creación de los productos del proyecto).
Project Manager Crear la Estrategia de Gestión del Riesgo.
Crear y mantener el Registro de Riesgos.
Asegurarse de que se identifiquen, evalúen y controlen los riesgos del proyecto durante
toda la vida del proyecto.
Team Manager Participar en la identificación, evaluación y control de riesgos.
Garantía del Proyecto Revisar las prácticas de gestión del riesgo para garantizar que se lleven a cabo en línea
con la Estrategia de Gestión del Riesgo del proyecto.
Apoyo al Proyecto Ayudar al Project Manager a mantener el Registro de Riesgos del proyecto.
Cambio 9
9 Cambio
9.1 Propósito
El propósito de la temática de Cambio es
identificar, evaluar y controlar cualquier cambio
potencial o aprobado que afecte a la baseline.
Es inevitable que existan cambios durante la
vida de un proyecto, y cada proyecto necesita
un enfoque sistemático para la identificación,
evaluación y control de cuestiones de las que
puedan derivar cambios.
Como los cambios pueden surgir de miembros
del equipo del proyecto, de solicitudes de partes
interesadas, de quejas o de muchos otros factores,
PRINCE2 proporciona un enfoque común hacia el
control de cambios y cuestiones.
PRINCE2 proporciona un enfoque que es a la
vez sistemático y común, y que garantiza que las
cuestiones que podrían afectar a las metas de
rendimiento del proyecto (tiempo, coste, calidad,
alcance, riesgo y beneficios) sean gestionadas
correctamente.
El control de cambios y cuestiones es una
actividad continua, que se lleva a cabo durante
toda la vida del proyecto. Sin un procedimiento
continuo y eficaz de control de cambios y
cuestiones, un proyecto se convertiría en algo
totalmente desligado de las partes interesadas o se
descontrolaría rápidamente.
La finalidad de los procedimientos de control de
cambios y cuestiones no es evitar los cambios, sino
garantizar que todos los cambios sean acordados
por la autoridad correspondiente antes de que
se accionen. El cambio es algo que solamente
se puede considerar en relación a un status quo
establecido, es decir, una baseline. Por lo tanto,
es un prerrequisito para un control de cambios y
cuestiones efectivo que se establezca un sistema
de gestión de la configuración adecuado que
registre baselines para los productos del proyecto y
garantice que se entreguen las versiones correctas
al cliente.
9.2 Definición de cambio
9.2.1 Control de cambios y cuestiones
Los procedimientos de control de cambios y
cuestiones aseguran que se identifiquen, se
evalúen y que o bien se aprueben, se rechacen o
se posterguen todos los cambios y cuestiones que
puedan afectar a las baselines acordadas para el
proyecto.
9.2.2 Gestión de la configuración
La gestión de la configuración es la actividad
técnica y administrativa relacionada con la
creación, el mantenimiento y el cambio controlado
de la configuración durante toda la vida de un
producto (o elemento).
Un elemento de configuración es una entidad que
está sujeta a la gestión de la configuración. La
entidad podría ser un componente de un producto,
un producto o un conjunto de productos que
constituyan una release. Por ejemplo:
■■ Un componente de un producto: un motor
eléctrico que sea parte de una máquina
■■ Un producto: una máquina
■■ Una release: una máquina, la sala de máquinas
reacondicionada, los materiales de capacitación
y los certificados necesarios de seguridad e
higiene.
Una release es un conjunto completo y coherente
de productos que son gestionados, probados y
distribuidos como una única entidad que se debe
entregar al usuario o usuarios.
Los procedimientos de control de cambios y
cuestiones tienen que integrarse en el sistema
de gestión de la configuración utilizado por el
proyecto.
104 | Cambio

9.2.3 Cuestiones 9.3 El enfoque de PRINCE2 hacia el

PRINCE2 utiliza el término “cuestión” para referirse
a cualquier evento importante que haya ocurrido,
que no estaba planificado y que requiera alguna
acción de gestión. Puede tratarse de asuntos,
dudas, solicitudes de cambio, sugerencias o fuera
de especificación planteados durante un proyecto.
Las cuestiones del proyecto pueden tratar cualquier
tema relacionado con el proyecto.
9.2.4 Tipos de cuestión
Las cuestiones pueden ser planteadas en cualquier
momento durante el proyecto, por parte de
cualquiera que tenga un interés en el proyecto o
en su resultado final.
La Tabla 9.1 proporciona un resumen de los
diferentes tipos de cuestión que necesitan
abordarse durante un proyecto.
cambio
9.3.1 Establecer controles
Los controles del proyecto para cuestiones,
cambios y para la gestión de la configuración serán
definidos y establecidos en el proceso del Inicio
de un Proyecto y, a continuación, revisados y, si
es necesario, actualizados hacia el final de cada
fase de gestión en el proceso de la Gestión de los
Límites de Fase. Los siguientes productos de gestión
se utilizan para establecer y mantener los controles
del proyecto para cuestiones, cambios y gestión de
la configuración:
■■ Estrategia de Gestión de la Configuración
■■ Fichas de Elementos de Configuración
■■ Informes sobre el Estado de los Productos
■■ Archivo Diario
■■ Registro de Cuestiones
■■ Informes de Cuestiones.

La importancia y uso de cada uno de estos

productos de gestión se describen en las secciones
9.3.1.1 a 9.3.1.6.

Tabla 9.1 Tipos de cuestión

Tipos de cuestión Definición Ejemplos
Solicitud de cambio Una propuesta de cambio a una versión Al Usuario Principal le gustaría aumentar
baseline. la capacidad de un producto de 100 a 150
usuarios.
Fuera de Algo que el proyecto debería proporcionar Un proveedor avisa de que ya no podrá
especificación pero que actualmente no hará (o se prevé entregar uno de los productos especificados
que no lo será). Esto podría ser un producto por el cliente.
que falta o un producto que no cumple su
especificación.
Problema/asunto Cualquier otra cuestión que el Project Manager Un Team Manager avisa de que un miembro
necesita resolver o para la cual debe presentar del equipo está de baja por enfermedad y, en
una excepción. consecuencia, la fecha objetivo final para un
Paquete de Trabajo sufrirá un retraso de una
semana.
La notificación de que uno de los proveedores
ha quebrado, lo que crea la necesidad de
identificar y llegar a un acuerdo con un nuevo
proveedor.

9.3.1.1 Estrategia de Gestión de la
Configuración
Solamente es posible un control de cambios y
cuestiones eficaz si éste cuenta con el apoyo de un
sistema de gestión de la configuración que facilite
las evaluaciones del impacto (relaciones entre
productos) y mantenga las versiones baseline de
los productos (la base a partir de la cual la entidad
cambiará).
El punto de partida para todos los proyectos
será identificar si existen políticas y procesos
corporativos o del programa que se necesitan
aplicar, e incorporarlos en la propia Estrategia
de Gestión de la Configuración del proyecto. La
Estrategia de Gestión de la Configuración del
proyecto debe definir:
■■ El procedimiento de gestión de la configuración
(por ejemplo, planificación, identificación,
control, informes sobre el estado, verificación y
auditoría)
■■ El procedimiento de control de cambios y
cuestiones (por ejemplo, registrar, examinar,
proponer, tomar decisiones, implementar)
■■ Las herramientas y técnicas que se utilizarán
■■ Los testimonios documentales que se
conservarán
■■ Cómo se informará sobre los rendimientos de
los procedimientos
■■ El calendario de las actividades de gestión de
la configuración y de control de cambios y
cuestiones
■■ Los roles y responsabilidades de las actividades
de gestión de la configuración y de control de
cambios y cuestiones (incluidos los roles de la
gerencia corporativa o del programa que vayan
a participar, si se da el caso).
La Estrategia de Gestión de la Configuración debe
definir el modo en que se abordan las cuestiones.
Durante la fase de inicio, el Project Manager y la
Junta de Proyecto tienen que acordar:
■■ La escala para ordenar cuestiones por prioridad
■■ La escala para clasificar la gravedad de las
cuestiones
■■ Las cuestiones de las que se debe ocupar cada
nivel de gestión según el grado de gravedad.
Cambio | 105
Ejemplo de prioridad y gravedad
Existen muchas formas de ordenar las cuestiones
por prioridad, una de las cuales se llama DDPN,
según la cual (en el caso de solicitudes de
cambio) la cuestión se clasifica como:
■■ Debe tener necesariamente El cambio es
fundamental para la viabilidad del proyecto
■■ Deberá tener El cambio es importante y su
ausencia debilita el Business Case
■■ Podría tener El cambio es útil pero su
ausencia no debilita al Business Case
■■ No tendrá (por ahora) El cambio no es
esencial ni importante y puede esperar.
Existen muchas formas de clasificar la
gravedad de las cuestiones, como por ejemplo
numéricamente (por ejemplo, de 1 a 4) o de
forma descriptiva (por ejemplo, de menor
importancia, importante, muy importante,
crucial). El Project Manager y la Junta de
Proyecto podrían acordar que de las cuestiones
de menor importancia se ocupe el Project
Manager y de las cuestiones importantes una
Autoridad de Cambios, pero para las cuestiones
muy importantes se tiene que presentar una
excepción a la Junta de Proyecto y para las
cuestiones cruciales a la gerencia corporativa o
del programa.
Al decidir qué nivel de gestión debe ocuparse
de cada tipo de cuestión según la gravedad, el
Project Manager puede considerar la opción
de delegar parte de la toma de decisiones para
aceptar/rechazar solicitudes de cambio o fuera
de especificación a una Autoridad de Cambios y
si se proporciona un presupuesto para pagar los
cambios:
■■ Autoridad de cambios Es una responsabilidad
de la Junta de Proyecto revisar y aprobar
solicitudes de cambio y fuera de especificación.
En un proyecto en el que se prevean pocos
cambios, puede ser razonable dejar esta
autoridad en manos de la Junta de Proyecto.
Sin embargo, en proyectos en los que sea
probable que existan muchos cambios, la Junta
de Proyecto podría optar por delegar algunas
decisiones a una persona o grupo, denominados
Autoridad de Cambios. El Project Manager y/o
las personas con responsabilidades delegadas
de Garantía del Proyecto pueden actuar como
106 | Cambio
Autoridad de Cambios. Podría ser apropiado,
por ejemplo, disponer que el Project Manager
sea la Autoridad de Cambios para Paquetes de
Trabajo, de modo que cualquier cambio que se
encuentre dentro de los límites de la autoridad
delegada se pueda llevar a cabo sin remitirlo a
la Junta de Proyecto para su aprobación
■■ Presupuesto para cambios Este consiste en una
suma de dinero que el cliente y el proveedor
acuerdan que se utilizará para financiar el
coste de solicitudes de cambio y, posiblemente,
también los costes de su análisis. Salvo que
el nivel de cambio previsto en un proyecto
sea bajo, es aconsejable que se establezca
un presupuesto para pagar los cambios. Esto
puede reducir la cantidad de excepciones de
poca importancia que surgen en proyectos
en los que se prevé que la frecuencia de
solicitudes de cambios será alta. Incluir un
presupuesto para cambios proporciona una
expectativa más realista de los costes/plazos
totales del proyecto. Cuando se facilite un
presupuesto para cambios a una Autoridad
de Cambios, la Junta de Proyecto podría
establecer un límite para (a) el coste de cada
cambio individual y (b) la cantidad que se
puede gastar en cambios en cada una de las
fases sin que sea necesaria una remisión a la
Junta de Proyecto. El procedimiento de control
de cambios se definiría entonces de modo
que se controle el acceso al presupuesto para
cambios. Si se utiliza, el presupuesto para el
control de cambios se documenta en el plan
correspondiente.
Véase una Descripción de Producto de una
Estrategia de Gestión de la Configuración en el
Apéndice A.
9.3.1.2 Fichas de Elementos de
Configuración
El propósito de las Fichas de Elementos de
Configuración es proporcionar un conjunto
de testimonios documentales que describan
información como el estado, la versión y la variante
de cada elemento de configuración y cualquier
dato de las relaciones importantes entre los
elementos.
Véase la Descripción de Producto de la Ficha de un
Elemento de Configuración en el Apéndice A.
9.3.1.3 Informe sobre el Estado de los
Productos
El propósito del Informe sobre el Estado de los
Productos es proporcionar información sobre
la condición de los productos dentro de límites
definidos. Estos límites pueden variar. Por ejemplo,
el informe puede cubrir todo el proyecto, una
fase concreta o un área específica del proyecto, o
incluso el historial de un solo producto. Resulta de
especial utilidad cuando el Project Manager quiere
confirmar los números de versión de los productos.
Véase la Descripción de Producto de un Informe
sobre el Estado de los Productos en el Apéndice A.
9.3.1.4 Archivo Diario
Un Archivo Diario se utiliza para dejar constancia
de problemas/asuntos que pueden ser manejados
informalmente por el Project Manager. Las
cuestiones registradas inicialmente en el Archivo
Diario se pueden transferir después al Registro de
Cuestiones si, una vez examinadas, se decide que
necesitan un tratamiento más formal.
El Archivo Diario se puede utilizar también
para registrar las acciones necesarias o los
acontecimientos importantes no recogidos en otros
registros y archivos de PRINCE2. Funciona como la
agenda del proyecto.
Véase la Descripción de Producto de un Archivo
Diario en el Apéndice A.
9.3.1.5 Registro de Cuestiones
El propósito del Registro de Cuestiones es registrar
y guardar información sobre todas las cuestiones
que se están gestionando formalmente. El Project
Manager debería hacer el seguimiento del Registro
de Cuestiones con regularidad.
Véase la Descripción de Producto de un Registro de
Cuestiones en el Apéndice A.
9.3.1.6 Informe de Cuestiones
Un Informe de Cuestiones es un informe que
contiene la descripción, la evaluación del impacto y
las recomendaciones para una solicitud de cambio,
un fuera de especificación o un problema/asunto.
Sólo se crea para aquellas cuestiones que necesitan
ser manejadas formalmente.

9.3.2 Procedimiento de gestión de la
configuración
Los procedimientos de gestión de la configuración
pueden variar, pero normalmente incluyen cinco
actividades fundamentales:
■■ Planificación Decidir qué nivel de gestión de la
configuración será requerido por el proyecto y
planificar cómo se logrará este nivel. El nivel
de control requerido variará de proyecto a
proyecto. El máximo nivel de control posible
se determina desglosando los productos del
proyecto hasta que se alcance el nivel en el que
un componente puede ser instalado, sustituido
o modificado de modo independiente. Sin
embargo, el nivel de control ejercido se verá
influido por la importancia del proyecto y la
complejidad de la relación entre sus productos
■■ Identificación Especificar e identificar todos los
componentes de los productos del proyecto
(conocidos como elementos de configuración) al
nivel de control requerido. Se debe establecer
un sistema de codificación, posibilitando que
se asigne a cada elemento de configuración
un identificador único y que se registren varios
atributos del producto
■■ Control La capacidad de aprobar y crear las
versiones baseline de los productos y de hacer
cambios solamente con el acuerdo de las
autoridades apropiadas. Cuando un producto
ha sido aprobado, el lema es “Nada se mueve y
nada se cambia sin autorización”. Una baseline
es un nivel de referencia en base al cual se
hace el seguimiento y controla una entidad.
En términos de gestión de la configuración,
es una imagen instantánea de una release, un
producto y cualquier producto componente,
congelada en un momento determinado para
un propósito concreto. Este propósito podría
ser cuando un producto está listo para ser
revisado o cuando ha sido aprobado. Si el
producto cuya versión baseline se ha creado
va a ser cambiado, se crea una nueva versión
para incluir el cambio, y la versión baseline se
mantiene sin cambios. Las versiones baseline
antiguas se deben archivar siempre que
sea posible, en vez de ser descartadas. El
control de la configuración también incluye:
el almacenamiento de toda la información
pertinente a la gestión del proyecto y el acceso
a ella; garantizar la seguridad de los elementos
de configuración y controlar quién tiene
Cambio | 107
acceso a ellos; distribuir copias de todos los
elementos de configuración; y archivar toda la
documentación elaborada durante la vida del
proyecto. Tanto los productos de gestión como
los productos especializados están sujetos a
control de la configuración.
■■ Informes sobre el estado Informar sobre todos
los datos actuales e históricos relativos a cada
producto, en forma de un Informe sobre el
Estado de los Productos. El Project Manager
podría solicitar un Informe sobre el Estado
de los Productos hacia el final de una fase, al
final del proyecto o como parte del examen de
cuestiones y riesgos
■■ Verificación y auditoría Una serie de revisiones
y auditorías de la configuración para comparar
el estado real de todos los productos con
la condición autorizada de los productos
registrada en las Fichas de Elementos de
Configuración, tratando de identificar cualquier
discrepancia. Estas revisiones y auditorías
también comprueban que el procedimiento de
gestión de la configuración se esté llevando a
cabo conforme a la Estrategia de Gestión de la
Configuración. Las revisiones se llevan a cabo
normalmente al final de cada fase y al final del
proyecto.
9.3.3 Procedimiento de control de
cambios y cuestiones
PRINCE2 proporciona un enfoque común para
la gestión de solicitudes de cambio, fuera de
especificación y problemas/asuntos, como se
muestra en la Figura 9.1.
9.3.3.1 Registrar
El primer paso del procedimiento es llevar a
cabo un análisis inicial para determinar el tipo
de cuestión que ha sido planteada y si se puede
gestionar de modo formal o informal.
Es probable que el Project Manager reciba muchas
cuestiones que se pueden abordar sin tener que
gestionarlas formalmente, especialmente si la
cuestión se puede resolver de modo inmediato. Por
ejemplo, un miembro del equipo podría plantear la
cuestión de que su pase de acceso a la sede está a
punto de caducar. En esos casos, el Project Manager
debe decidir cuál es la mejor rectificación.
El propósito de diferenciar las cuestiones que se
pueden gestionar de modo informal de las que
necesitan gestionarse formalmente es:
108 | Cambio

Figura 9.1 Procedimiento de control de cambios y cuestiones

Junta de Proyecto/Autoridad de Cambios

Solicitud de asesoramiento Solicitud de asesoramiento /

Informe de Excepción

Registrar Examinar Proponer Decidir Implementar

• Determinar el • Evaluar el
• Identificar • Presentar una • Rectificar
tipo de cuestión impacto en los
opciones excepción si más • Actualizar los
• Determinar la objetivos o
• Evaluar allá de la testimonios
severidad/ Business Case y
opciones autoridad documentales
prioridad en el perfil de
• Recomendar delegada y los planes
• Registro riesgo del
opciones • Aprobar,
Archivo proyecto
rechazar o
• Comprobar
diferir la
severidad/
opción
prioridad
recomendada

Archivo Diario o
Registro de Cuestiones/Informe de Cuestiones

■■ Asegurarse de que se tomen las decisiones en el
nivel apropiado dentro del equipo de gestión
del proyecto
■■ Evitar que la Junta de Proyecto se vea inundada
con demasiadas cuestiones y, por lo tanto,
aprovechar el tiempo del que dispone para
gestionar cuestiones principales que afecten al
proyecto
■■ Reducir la carga administrativa del Project
Manager a la hora de gestionar cuestiones
diarias que puedan surgir.
Las cuestiones que se gestionan formalmente se
deben anotar en el Registro de Cuestiones y se les
debe asignar un identificador único. Se debe crear
un Informe de Cuestiones para registrar lo que ya
se sabe sobre la cuestión. A menudo resulta de
utilidad pedir a la persona que planteó la cuestión
que elabore el Informe de Cuestiones inicial.
9.3.3.2 Examinar
El siguiente paso es examinar la cuestión llevando a
cabo un análisis del impacto.
El Project Manager tiene que considerar si merece
la pena hacer un análisis detallado del impacto, ya
que la duración y esfuerzo requeridos para llevarlo
a cabo pueden causar en sí mismos una desviación
respecto del plan.
El análisis del impacto debe considerar el impacto
que la cuestión tiene (o tendrá) sobre:
■■ Las metas de rendimiento del proyecto respecto
del tiempo, coste, calidad y alcance
■■ El Business Case del proyecto, especialmente en
lo relativo al impacto sobre los beneficios
■■ El perfil de riesgo del proyecto, es decir, el
impacto sobre la exposición total al riesgo del
proyecto.
Si el proyecto forma parte de un programa, se
debe considerar el impacto del cambio sobre el
programa en su totalidad. También pueden existir
efectos sobre otros proyectos que no formen
necesariamente parte del programa.
Examinar el impacto de las cuestiones puede
erróneamente entenderse como el impacto
para el cliente solamente. El análisis del impacto
debe necesariamente cubrir las tres áreas;
comercial, usuario y proveedor. Por ejemplo,
el coste y esfuerzo del proveedor requeridos
para implementar un cambio y qué productos
se tendrían que cambiar. Tras haber realizado el
análisis del impacto, se debe revaluar la gravedad
y/o prioridad.
El Registro de Cuestiones y el Informe de
Cuestiones se deben actualizar para incluir la
información mencionada anteriormente, y se debe
 Cambio | 109

mantener a la persona que planteó la cuestión y a Si cualquiera de las opciones propuestas hiciera que
la persona que creó el Informe de Cuestiones (si no la fase o el proyecto excedieran alguna tolerancia,
es la misma) informadas sobre su estado. se deberá considerar la elaboración de un Informe
de Excepción para esa opción que acompañe al
Podría ser necesario pedir asesoramiento a la Junta
Informe de Cuestiones.
de Proyecto para conocer su punto de vista sobre
la prioridad o gravedad de la cuestión, antes de
proponer resoluciones.
9.3.3.4 Decidir
El Project Manager podría ser capaz de resolver
9.3.3.3 Proponer cuestiones sin la necesidad de presentar
excepciones a la Junta de Proyecto. Por ejemplo, un
Tras haber comprendido totalmente el impacto
cambio de menor importancia en un documento
de la cuestión, el siguiente paso es considerar las
de diseño detallado ya aprobado que no afecte
distintas opciones alternativas para responder a
a ninguno de los otros productos podría ser
ella y proponer las medidas que se tendrían que
gestionado por el Project Manager (si lo permite la
adoptar.
Estrategia de Gestión de la Configuración), siempre
Se debe considerar el efecto que cada una de las que se registre formalmente.
opciones tendrá sobre las metas de rendimiento
Otras cuestiones podrían tener que remitirse a la
de tiempo, coste, calidad, alcance, beneficio y
Junta de Proyecto (o a su Autoridad de Cambios
riesgo del proyecto. Debe existir necesariamente
delegada) para que tome una decisión. La remisión
un equilibrio entre las ventajas derivadas de
puede hacerse en forma de Informe de Cuestiones
implementar la opción, y el tiempo, coste y riesgo
(como parte de una solicitud de asesoramiento)
de implementarla, como se muestra en la
o en forma de Informe de Excepción (si la opción
Figura 9.2.
elegida para abordar la cuestión provocara una
excepción – véase el Capítulo 10).
Ventaja Impacto de la
Para cuestiones y excepciones presentadas, las
obtenida implementación
probables respuestas de la Junta de Proyecto se
muestran en la Tabla 9.2.

/ 9.3.3.5 Implementar
Costes/tiempo
do s
riesgos reduci El Project Manager hará una de estas dos cosas:
■■ Llevará a cabo las rectificaciones necesarias
n
Coste/duració (como, por ejemplo, actualizar un Paquete de
de la opción
ás beneficios
Trabajo o emitir uno nuevo), o
M
■■ Preparará un Plan de Excepción para someterlo
a la aprobación de la Junta de Proyecto.
Riesgo
En ambos casos, el Project Manager actualizará el
etc. de la opción
Registro de Cuestiones y el Informe de Cuestiones
con la decisión adoptada e informará a todas las
partes interesadas.
Una vez cerrada la cuestión, el Project Manager
debe actualizar el Registro de Cuestiones y el
Informe de Cuestiones.
Figura 9.2 Análisis de las opciones

Las consideraciones sobre el riesgo deben incluir

tanto riesgos del proyecto (es decir, el riesgo de
que no se complete dentro de las tolerancias) así
como riesgos opcionales (por ejemplo, posibles
cuestiones de rendimiento, una vez que los
productos del proyecto están en funcionamiento).
110 | Cambio

Tabla 9.2 Decisiones de la Junta de Proyecto

Solicitud Respuesta de la Junta de Proyecto Consideraciones

(o Autoridad de Cambios)
Solicitud de ■■ Aprobar el cambio Si una solicitud de cambio implica un coste
cambio ■■ Rechazar el cambio adicional, existen tres modos principales de
financiarla:
■■ Postergar la decisión
■■ Usar el presupuesto para cambios (si
■■ Solicitar más información se está haciendo uso de uno y si es lo
■■ Solicitar un Plan de Excepción (si la solicitud suficientemente grande)
de cambio no se puede implementar dentro ■■ Aumentar el presupuesto para cambios
de los límites delegados a la Autoridad de
■■ Sacar del alcance otros elementos del
Cambios).
proyecto.
No se deben utilizar las tolerancias para
financiar solicitudes de cambio.
Fuera de ■■ Otorgar una concesión La Junta de Proyecto podría decidir que
especificación ■■ Ordenar que se resuelva el fuera de se acepte el fuera de especificación sin
especificación rectificaciones inmediatas. Esto se conoce
como concesión. Cuando se otorga una
■■ Postergar la decisión
concesión a un producto, la Descripción de
■■ Solicitar más información Producto se tendrá que revisar antes de que se
■■ Solicitar un Plan de Excepción (si la concesión entregue el producto al Usuario.
no se puede otorgar dentro de los límites
delegados a la Autoridad de Cambios).
Problema/asunto ■■ Proporcionar asesoramiento ¿Se podría resolver el problema/asunto
■■ Solicitar un Plan de Excepción flexibilizando las tolerancias de la fase?
 Cambio | 111

9.4 Responsabilidades
La Tabla 9.3 resume las responsabilidades
relacionadas con la temática del Cambio. Véase
el Apéndice C para más información sobre los
roles del equipo de gestión del proyecto y sus
responsabilidades asociadas.

Tabla 9.3 Responsabilidades relacionadas con la temática de Cambio

Rol Responsabilidades
Gerencia corporativa o del Proporcionar la estrategia corporativa o del programa para el control de cambios, la resolución
programa de cuestiones y la gestión de la configuración.
Ejecutivo Determinar la Autoridad de Cambios y el presupuesto para cambios.
Fijar la escala para la clasificación de la gravedad de las cuestiones.
Fijar la escala para la clasificación de la prioridad de las solicitudes de cambio y fuera de
especificación.
Responder a las solicitudes de asesoramiento del Project Manager.
Tomar decisiones sobre las cuestiones que se le han remitido, teniendo especialmente en
cuenta la justificación comercial continua.
Usuario Principal Responder a las solicitudes de asesoramiento del Project Manager.
Tomar decisiones sobre las cuestiones que se le han remitido, teniendo especialmente en cuenta
la preservación de los beneficios esperados.
Proveedor Principal Responder a las solicitudes de asesoramiento del Project Manager.
Tomar decisiones sobre las cuestiones que se le han remitido, teniendo especialmente en
cuenta la protección de la integridad de toda la solución.
Project Manager Gestionar el procedimiento de gestión de la configuración, con la ayuda del Apoyo al
Proyecto cuando sea posible.
Gestionar el procedimiento de control de cambios y cuestiones, con la ayuda del Apoyo al
Proyecto cuando sea posible.
Crear y mantener el Registro de Cuestiones, con la ayuda del Apoyo al Proyecto cuando sea
posible.
Implementar rectificaciones.
Team Manager Implementar rectificaciones.
Garantía del Proyecto Asesorar sobre el examen y resolución de cuestiones.
Apoyo al Proyecto Administrar los procedimientos de gestión de la configuración y de control de cambios y
cuestiones:
■■ Mantener Fichas de Elementos de Configuración
■■ Crear Informes sobre el Estado de los Productos
■■ Ayudar al Project Manager a mantener el Registro de Cuestiones.
 10
Progreso
10 Progreso
10.1 Propósito
El propósito de la temática de Progreso
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.
Dos de los principios de PRINCE2 son la gestión
por fases y la justificación comercial continua. La
temática del Progreso proporciona los mecanismos
para el seguimiento y el control, posibilitando la
evaluación crítica de la viabilidad continua.
La temática del Progreso proporciona esos
mecanismos para todos los niveles de gestión
(entrega, gestión, dirección) dentro del equipo de
gestión del proyecto, y para la gerencia corporativa
o del programa fuera del proyecto.
Otro principio de PRINCE2 es la gestión por
excepción en los proyectos, fijando tolerancias
para los objetivos del proyecto, para establecer los
límites de la autoridad delegada. Las tolerancias
definen el grado de discrecionalidad que cada nivel
de gestión puede ejercer sin que sea necesario
acudir al nivel de gestión inmediatamente superior
para obtener una aprobación. La temática del
Progreso proporciona los mecanismos para hacer
un seguimiento del progreso, comparándolo con
las tolerancias permitidas, y los controles para
presentar excepciones al nivel apropiado si algún
pronóstico indica que se excederán una o más
tolerancias.
El control del progreso está relacionado
fundamentalmente con la toma de decisiones y es
algo esencial en la gestión de proyectos, ya que
garantiza que el proyecto se mantiene viable en
base a su Business Case aprobado.
10.2 Definición de progreso
10.2.1 ¿Qué es el progreso?
El progreso es la medición del logro de los
objetivos de un plan. Se puede hacer su
seguimiento a nivel de Paquete de Trabajo, de fase
y de proyecto.
10.2.2 ¿Qué son los controles del
progreso?
Los controles del progreso garantizan que, para
cada nivel del equipo de gestión del proyecto, el
nivel de gestión inmediatamente superior puede:
■■ Hacer un seguimiento del progreso
■■ Comparar el nivel de logro de los objetivos con
el plan
■■ Revisar planes y opciones para afrontar
situaciones futuras
■■ Detectar problemas e identificar riesgos
■■ Iniciar rectificaciones
■■ Autorizar trabajo adicional.
10.2.3 Excepciones y tolerancias
Una excepción es una situación en la que se puede
prever que tendrá lugar una desviación por encima
de los niveles de tolerancia acordados.
Las tolerancias son 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. También podría haber
niveles de tolerancia para calidad, alcance,
beneficios y riesgo.
Si no se implementan las tolerancias, no hay
una manera clara para definir los límites de
discrecionalidad si las cosas no salen según
lo previsto en el plan. Por ejemplo, si cada
desviación, por más pequeña que sea, se presenta
como una excepción a la Junta de Proyecto, el
Project Manager solamente estaría haciendo un
seguimiento del trabajo y no estaría haciendo
esfuerzo alguno por implantar rectificaciones,
situación que, evidentemente, no sería satisfactoria
desde el punto de vista de los miembros de
116 | Progreso

la Junta de Proyecto. De hecho, la Junta de 10.3 El enfoque de PRINCE2 sobre el

Proyecto estaría haciendo el trabajo del Project
Manager. Por otro lado, si el Project Manager
implementase rectificación tras rectificación se
correría el riesgo de que los miembros de la Junta
de Proyecto interpretasen esto como un abuso
de su discreción (al no estar ésta definida por
escrito) y cuestionasen por qué no se plantearon
excepciones antes. En este caso, la percepción
sería que el Project Manager está asumiendo el
rol de la Junta de Proyecto. La Tabla 10.1 describe
en qué aspectos se pueden aplicar con éxito las
tolerancias y muestra en qué producto de gestión
se documentan.
Tabla 10.1 Las seis áreas de tolerancia por nivel
progreso
El control del progreso implica medir el progreso
real, comparándolo con las metas de rendimiento
de tiempo, coste, calidad, alcance, beneficios y
riesgo, y a continuación utilizar esta información
para tomar decisiones (como, por ejemplo, si se
aprueba una fase o un Paquete de Trabajo, si una
desviación se presenta como excepción, si se cierra
prematuramente el proyecto, etc.) y realizar las
acciones necesarias. PRINCE2 proporciona el control
del progreso mediante:

Tolerancias a
Tolerancias a Tolerancias a Tolerancias a
nivel de
Áreas de tolerancia nivel de nivel de nivel de
Paquete de
proyecto fase producto
Trabajo
Tiempo
+/- cantidades de tiempo respecto Plan de Plan de la N/C
de fechas de terminación previstas Proyecto Fase

Coste Plan de Plan de la Paquete

N/C
+/- montos de presupuesto planificado Proyecto Fase de Trabajo

Alcance
Variación permitida del alcance de una
Plan de Plan de la Paquete
solución de proyecto, por ej., técnica de N/C
Proyecto Fase de Trabajo
ordenación de exigencias por prioridad (se Debe
obtener, se Debería obtener, se Podría
obtener o No se obtendrá por ahora (DDPN).
(nota 1) (nota 1) (nota 1)
Riesgo
Límite al valor total de las amenazas (por ej., el Estrategia
valor monetario previsto deberá ser inferior al Plan de la Paquete N/C
de Gestión Fase de Trabajo
10% del presupuesto para el plan); y Límite
respecto de cualquier amenaza individual del Riesgo
(por ej., cualquier amenaza al servicio operacional) (nota 2) (nota 2)
Calidad Descripción N/C N/C Descripción
Definir metas de calidad en términos de gamas; del Producto
de Producto
por ej., un producto que pesa 300g +/- 10g del Proyecto (nota 3) (nota 3)
Beneficios
Definir beneficios esperados en términos de
gamas, por ej., lograr ahorros mínimos en coste Business
N/C N/C N/C
de 5% por sucursal, con un promedio de 7% Case
en todas las sucursales

Nota 1 – el alcance de un plan se define por el conjunto de productos a entregar. La tolerancia de alcance
(si se utiliza) debería tomar la forma de una nota en la estructura jerárquica de productos para el plan o una
referencia a ésta. La tolerancia de alcance a nivel de fase o de Paquete de Trabajo es particularmente útil si
se está aplicando un método de desarrollo iterativo limitado en el tiempo como Agile.

Nota 2 – la Junta de Proyecto podrá fijar tolerancias de riesgos más específicas a nivel de fase al autorizar una
fase o el Project Manager las podrá fijar al encargar Paquetes de Trabajo, especialmente de proveedores externos.

Note 3 – las tolerancias de calidad no se definen sumariamente a nivel de fase o de Paquete de Trabajo pero
son definidas según cada Descripción de Producto dentro del alcance del plan.
 Progreso | 117

■■ La delegación de autoridad de un nivel de

Gestión corporativa o del programa
gestión al nivel inmediatamente inferior
■■ La división del proyecto en fases de gestión y la
autorización de las fases del proyecto una por
Tolerancias a Progreso/excepciones
una
nivel de proyecto del proyecto
■■ Revisiones y presentación de informes sobre
el progreso basadas en tiempo y basadas en
eventos
Junta de Proyecto
■■ La presentación de excepciones.

Los controles del proyecto se deben documentar en

la Documentación de Inicio del Proyecto. Tolerancias a Progreso/excepciones
nivel de fase de la fase
10.3.1 Delegación de autoridad
10.3.1.1 Los cuatro niveles de gestión Project Manager
El principio de gestión por excepción utiliza seis
tipos de tolerancia, en base a los cuales se puede
controlar un proyecto. La asignación de tolerancias Tolerancias a nivel Progreso/cuestiones
se ajusta a los cuatro niveles del equipo de gestión de Paquete de Trabajo del Paquete de Trabajo
del proyecto, que se muestran en la Figura 10.1 y se
describen a continuación:
Team Manager
■■ La gerencia corporativa o del programa se sitúa
fuera del proyecto, pero establece las exigencias
generales y los niveles de tolerancia para el Figura 10.1 Delegación de tolerancia y presentación
proyecto. Los tres niveles de gestión dentro de informes sobre el progreso real y previsto
del proyecto (responsables de la dirección, la
gestión y la entrega) llevarán a cabo la gestión
la fase, el Project Manager debe informar de
e implementación dentro de esas tolerancias
la desviación a la Junta de Proyecto para que
y presentarán como excepción cualquier
tome una decisión sobre las rectificaciones
incumplimiento que se prevea respecto de la
■■ El Team Manager tiene el control de un
tolerancia del proyecto
Paquete de Trabajo, pero solamente dentro
■■ La Junta de Proyecto tiene el control general a
de las tolerancias para el Paquete de Trabajo
nivel de proyecto, siempre que los pronósticos
acordadas con el Project Manager. Durante la
se mantengan dentro de la tolerancia del
ejecución del Paquete de Trabajo, si alguna
proyecto, y asignará al Project Manager
previsión indica que es probable que se excedan
tolerancias para cada fase de gestión. La Junta
las tolerancias acordadas, el Team Manager
de Proyecto tiene la capacidad de revisar el
debe informar de la desviación al Project
progreso y decidir si continuar, cambiar o
Manager para que tome una decisión sobre las
parar el proyecto. Durante la ejecución del
rectificaciones.
Plan de Proyecto, si alguna previsión indica
que es probable que el proyecto exceda las
10.3.1.2 Controles de la Junta de Proyecto
tolerancias acordadas para el proyecto, la Junta
de Proyecto debe informar de la desviación a la Los controles principales de los que dispone la
gerencia corporativa o del programa para que Junta de Proyecto incluyen:
tome una decisión sobre las rectificaciones ■■ Autorizaciones La Junta de Proyecto utiliza
■■ El Project Manager tiene el control diario de el proceso de la Dirección de un Proyecto
una fase de gestión dentro de los límites de para autorizar el inicio, autorizar el proyecto,
tolerancia establecidos por la Junta de Proyecto. autorizar cada fase y, por último, autorizar el
Durante la ejecución de un Plan de la Fase, si cierre del proyecto:
alguna previsión indica que es probable que ●● Después del proceso, previo al proyecto, de
la fase exceda las tolerancias acordadas para la Puesta en Marcha de un Proyecto, la Junta
118 | Progreso
de Proyecto autoriza que se progrese a la
fase de inicio, que es el “comienzo” oficial
del proyecto
●● Después del proceso del Inicio de un
Proyecto, la Junta de Proyecto revisa la
información de la Documentación de Inicio
del Proyecto y, si considera que existen
suficientes motivos para proceder con el
proyecto, puede aprobar la Documentación
de Inicio del Proyecto y autorizar el propio
proyecto
●● Después del proceso de la Gestión de los
Límites de Fase, la Junta de Proyecto revisa
un Plan de la Fase o un Plan de Excepción,
y puede aprobar el plan, con sus tolerancias
correspondientes para la siguiente fase de
gestión, o, si no existe justificación suficiente
para continuar con el proyecto, activar el
cierre prematuro del proyecto
●● Después del proceso del Cierre de un
Proyecto, la Junta de Proyecto revisa el
Informe al Final de Proyecto y, si considera
que el proyecto está completo o no tiene
nada más que ofrecer, puede autorizar su
cierre
■■ Actualizaciones sobre el progreso Incluyen los
Informes de Desarrollo y los Informes al Final de
Fase
■■ Excepciones y cambios Incluyen los Informes de
Excepción y los Informes de Cuestiones.
Cuando la Junta de Proyecto ha acordado con el
Project Manager las tolerancias para la fase, se la
mantiene informada sobre el progreso mediante
Informes de Desarrollo. No es necesario celebrar
reuniones regulares sobre el progreso durante esta
fase, aunque el personal con responsabilidades
de Garantía del Proyecto tendrá que estar
regularmente en contacto con el Project Manager y
los miembros del equipo.
10.3.1.3 Controles del Project Manager
Los controles principales de los que dispone el
Project Manager incluyen:
■■ Autorizaciones Las autorizaciones del Project
Manager tienen lugar durante el proceso del
Control de una Fase (véase el Capítulo 15). El
Project Manager será responsable de acordar y
autorizar Paquetes de Trabajo y tolerancias para
los Paquetes de Trabajo
■■ Actualizaciones sobre el progreso Incluyen
Informes del Punto de Control elaborados por
los Team Managers o los miembros del equipo
■■ Excepciones y cambios Uso de los registros y
archivos del proyecto para revisar el progreso
e identificar cuestiones y riesgos que podrían
tener que resolverse. Se da más información
sobre éstos en la sección 10.3.3.2.
10.3.2 Uso de las fases de gestión para
ejercer control
Las fases de gestión son subdivisiones del proyecto
con puntos de decisión sobre la gestión. Una
fase de gestión es un conjunto de actividades y
productos cuya entrega se gestiona como una
unidad. Como tal, esta fase es un subconjunto del
proyecto y, en relación a PRINCE2, es el elemento
de trabajo que gestiona el Project Manager en
nombre de la Junta de Proyecto en cualquier
momento.
Fases de gestión:
■■ Proporcionan puntos de revisión y decisión,
dando a la Junta de Proyecto la oportunidad de
evaluar la viabilidad del proyecto en intervalos
regulares, en vez de dejar que transcurra de
forma incontrolada
■■ Proporcionan la capacidad para garantizar
que las decisiones principales se llevan a cabo
antes que el trabajo detallado necesario para
implementarlas
■■ Permiten la aclaración de cuál será el impacto
de una influencia externa identificada, como
podría ser la sesión presupuestaria corporativa
o la conclusión de legislación
■■ Facilitan el principio de la gestión por excepción
delegando autoridad al Project Manager fase
por fase.
La Junta de Proyecto autoriza las fases de gestión
del proyecto una por una. Hacia el final de cada
fase, durante el proceso de la Gestión de los
Límites de Fase, el Project Manager revisará el
Business Case y el Plan de Proyecto, actualizará la
documentación del proyecto con los resultados de
la fase y creará un Informe al Final de Fase y un
Plan de la Fase, para solicitar la autorización para
comenzar la siguiente fase de gestión. El Informe
al Final de Fase, junto con el Plan de la Fase para la
fase siguiente, debe contener toda la información
necesaria para posibilitar que la Junta de Proyecto
lleve a cabo una evaluación al final de fase y tome

una decisión sobre si se sigue adelante. La Junta
de Proyecto solamente autoriza la siguiente fase
de gestión si existe una justificación comercial
suficiente para continuar. Si el proyecto deja de
tener un Business Case válido, la Junta de Proyecto
tiene la autoridad para cerrar prematuramente el
proyecto.
La Junta de Proyecto delega al Project Manager
la autoridad para el control diario de una fase,
dentro de las tolerancias acordadas. Siempre
que se prevea que la fase se mantendrá dentro
de la tolerancia, el Project Manager tiene la
facultad discrecional de hacer los ajustes que sean
necesarios. Esto permite a la Junta de Proyecto
realizar gestión por excepción, reteniendo el nivel
de control que necesita, a la vez que se reduce la
carga administrativa de tener que participar.
10.3.2.1 Número de fases
El uso de fases de gestión en un proyecto de
PRINCE2 es obligatorio, pero el número de fases
es flexible y depende del tamaño y del factor
de riesgo del proyecto. Todos los proyectos de
PRINCE2 tienen al menos dos fases de gestión. La
fase de inicio es obligatoria, ya que garantiza que
exista una base sólida para el proyecto y que ésta
sea comprendida por todas las partes. También
debe existir al menos una fase de gestión más
para abarcar el resto del proyecto. Para proyectos
más grandes, podrían ser necesarias fases de
gestión adicionales para posibilitar que el equipo
de gestión del proyecto cuente con el nivel de
planificación y control más apropiado.
Definir las fases de gestión es fundamentalmente
un proceso de equilibrar lo siguiente:
■■ Hasta qué punto del proyecto es razonable
planificar
■■ Dónde tienen que estar los puntos principales
de decisión del proyecto
■■ La cantidad de riesgo dentro de un proyecto
■■ Demasiadas fases de gestión cortas (lo que
aumenta la carga de gestión del proyecto)
frente a muy pocas fases, pero largas (lo que
disminuye el nivel de control)
■■ Qué grado de seguridad tienen la Junta de
Proyecto y el Project Manager de que se debe
seguir adelante.
El número de fases de gestión necesarias vendrá
determinado por la naturaleza del proyecto y su
duración. Para proyectos de corta duración (por
Progreso | 119
ejemplo, aquellos en los que el proyecto se puede
completar dentro del horizonte de planificación),
la inclusión de múltiples fases de gestión podría
resultar en “cargas” innecesarias y costes
adicionales.
10.3.2.2 Duración de las fases
PRINCE2 no define cuánto debe durar una fase
de gestión. Las fases deben ser más cortas cuanto
mayor es el factor de riesgo, la incertidumbre o
la complejidad, por ejemplo, al principio y al final
de los proyectos. Pueden ser más largas cuando
el riesgo es menor, normalmente en las etapas
intermedias de los proyectos. Además, la duración
de las fases de gestión puede variar dependiendo
del punto dentro del ciclo de vida del proyecto. Los
factores que influirán en esta decisión incluyen:
■■ El horizonte de planificación en cualquier
momento determinado El horizonte de
planificación puede variar dependiendo
de la naturaleza del trabajo que se lleva a
cabo. Por ejemplo, el trabajo necesario para
instalar un sistema informático durante un
proyecto de migración de una aplicación se
puede comprender mejor y puede ser menos
arriesgado que el trabajo necesario para llevar
a cabo la propia migración de la aplicación
■■ Las fases técnicas dentro del proyecto El final
de las fases de gestión no tiene que tener lugar
necesariamente al mismo tiempo que el final
de las fases técnicas, pero a menudo existen
ventajas si coinciden. Por ejemplo, la Junta de
Proyecto podría estar interesada en los efectos
de los resultados de una “prueba de concepto”
sobre el Business Case, antes de comprometerse
a un despliegue a escala completa
■■ Alineación con las actividades del programa
Puede existir la exigencia de alinear el final de
una fase de gestión con la revisión al final de
un tramo dentro del programa. Esto posibilitará
que el proyecto contribuya plenamente a la
evaluación de la viabilidad continua del propio
programa
■■ El nivel de riesgo Las fases de gestión pueden
resultar muy útiles como medio de proporcionar
el control de la Junta de Proyecto a proyectos
arriesgados. Las divisiones entre fases se
pueden insertar en momentos clave cuando se
pueden revisar los riesgos del proyecto antes
de comprometer en gran medida dinero o
recursos.
120 | Progreso

10.3.2.3 Fases técnicas Un enfoque distinto conllevaría el riesgo de

Otro método para agrupar trabajo es en base al que el proyecto se viera dirigido por los equipos
conjunto de técnicas utilizadas o los productos especializados, en vez de la gerencia del cliente.
creados. Esto da por resultado fases que cubren
Proyecto
elementos tales como diseño, construcción e
implementación. Estas fases son fases técnicas y son Especificar
un concepto independiente de las fases de gestión
ya descritas. Diseñar

Las fases técnicas a menudo se sobreponen (como

Construir
en las Figuras 10.2 y 10.3), pero las fases de
gestión no. Las fases técnicas se caracterizan por
Formar
el uso de un conjunto específico de competencias
especializadas. Las fases de gestión tienen que ver
con el compromiso de recursos y la autoridad para Encargar
gastar.
A menudo, el límite de los dos tipos de fase Figura 10.2 Trabajo especializado definido en fases
coincidirá. Por ejemplo, en el caso en que la técnicas
decisión de gestión se base en el resultado de la
fase técnica. Sin embargo, en otros casos los límites Proyecto
de fase no coincidirán. Por ejemplo, podría haber Fase de gestión 1 Fase de gestión 2 Fase de gestión 3 Fase de gestión 4
más de una fase técnica durante cada fase de
gestión. Especificar

Cuando una fase técnica se alargue más allá del

Diseñar
límite de una fase de gestión, la medida en que
el producto o productos de la fase técnica deben
Construir
haber sido completados al llegar al límite de
fase debe estar clara en la(s) Descripción(es) de
Capacitar
Producto(s) correspondiente(s).
Las Figuras 10.2, 10.3 y 10.4 proporcionan ejemplos
Autorizar la puesta en Servicio
de la distinción entre fases técnicas y de gestión.
La Figura 10.2 muestra un proyecto con cinco fases
técnicas. Figura 10.3 Trabajo especializado que cruza
márgenes de fases de gestión
La Figura 10.3 muestra el mismo proyecto que
la Figura 10.2, pero dividido en cuatro fases de
gestión. Dos de las fases técnicas se extienden en Proyecto
más de una fase de gestión. Fase de gestión 1 Fase de gestión 2 Fase de gestión 3 Fase de gestión 4

La Figura 10.4 muestra que la fase técnica

Especificación
de “diseñar” se ha dividido en tres grupos
de productos. El diseño general queda ahora Diseño Diseño Diseño
general detallado periférico
cubierto dentro de la fase de gestión 1; el diseño
detallado y el programa de capacitación forman Instalaciones
construidas
la segunda fase de gestión; y el diseño periférico
está programado para la fase de gestión 3, junto Programa de
formación
Personal
formado
con la creación de las instalaciones construidas y el
personal capacitado.
Instalaciones puestas
El enfoque de PRINCE2 consiste en concentrar en servicio

la gestión del proyecto en fases de gestión, ya

que éstas forman la base de los procesos de Figura 10.4 Trabajo especializado alineado con las
planificación y control descritos en todo el método. fases de gestión

10.3.3 Controles basados en eventos y
basados en tiempo
PRINCE2 proporciona dos tipos de control del
progreso a lo largo de la vida de un proyecto:
■■ Controles basados en eventos Tienen lugar
cuando ocurre un evento específico. Esto
podría ser, por ejemplo, el final de una fase,
la finalización de la Documentación de Inicio
del Proyecto o la creación de un Informe de
Excepción. También podría incluir eventos de
organización que podrían afectar al proyecto,
como por ejemplo el final del año fiscal
■■ Controles basados en tiempo Tienen lugar en
intervalos periódicos previamente definidos.
Esto podría ser, por ejemplo, la elaboración de
Informes de Desarrollo mensuales para la Junta
de Proyecto o de Informes del Punto de Control
semanales que muestren el progreso de un
Paquete de Trabajo.
El seguimiento y la presentación de informes
periódicos requieren un enfoque basado en
tiempo, mientras que el control (toma de
decisiones) es una actividad basada en eventos.
Las siguientes secciones describen los productos de
gestión que se utilizan para establecer y ejecutar
controles basados en eventos y basados en tiempo.
10.3.3.1 Baselines para el control del
progreso
El nivel de granularidad del control depende
directamente del nivel de resolución de los planes.
Es decir, si se quiere tener Informes del Punto de
Control semanalmente, se necesita saber en el Plan
de la Fase qué se espera lograr semana por semana.
Los siguientes productos de gestión ayudan al
Project Manager a establecer baselines para el
control del progreso:
■■ Plan de Proyecto Este incluirá las metas
de rendimiento y las tolerancias a nivel de
proyecto. Cualquier amenaza a las tolerancias
a nivel de proyecto tiene que presentarse como
excepción a la Junta de Proyecto, que pedirá
asesoramiento a la gerencia corporativa o del
programa sobre las rectificaciones a realizar
■■ Planes de Fase Estos forman la base del control
diario de la fase. Deben incluir información
sobre las actividades que se deben llevar a cabo
durante una fase de gestión, sus calendarios y
los recursos necesarios para llevarlas a cabo
Progreso | 121
■■ Plan de Excepción La Junta de Proyecto podría
solicitar un Plan de Excepción después de haber
examinado un Informe de Excepción, durante el
proceso de la Dirección de un Proyecto. El Plan
de Excepción debe ser elaborado al mismo nivel
que el plan al que sustituye
■■ Paquetes de Trabajo El Project Manager
autoriza un Paquete de Trabajo para hacer
que un miembro individual del equipo o un
Team Manager lleve a cabo un determinado
trabajo durante una fase. Esto significa que no
se puede llevar a cabo un trabajo salvo que el
Project Manager lo haya autorizado de modo
específico. La información detallada sobre qué
trabajo se tiene que completar y dentro de qué
tolerancias debe ser acordada entre el Project
Manager y el Team Manager (o miembro del
equipo) y documentada en el Paquete de
Trabajo. La autorización de un Paquete de
Trabajo es un control especialmente útil a la
hora de tratar con contratistas y subcontratistas.
Las personas o equipos hacen un seguimiento
del progreso comparándolo con el Paquete
de Trabajo y mantienen actualizado al Project
Manager por medio de lnformes del Punto de
Control. Un proyecto puede ser una mezcla
de equipos internos y externos. Por lo tanto,
podría ser aceptable utilizar una mezcla de
Paquetes de Trabajo formales e informales, de
distintos tamaños, con tolerancias amplias o
estrechas, dependiendo de las necesidades del
proyecto.
10.3.3.2 Revisión del progreso
Como parte del Control de una Fase, el Project
Manager revisará regularmente el progreso del
trabajo mediante Informes del Punto de Control
y mantendrá un conjunto de registros y archivos
del proyecto. El Project Manager usará esta
información para actualizar el Plan de la Fase con
el progreso real que se haya logrado. La frecuencia
requerida para la elaboración de Informes del
Punto de Control puede variar de acuerdo con
las necesidades de cada Paquete de Trabajo en
particular.
También resulta útil fijarse en las tendencias para
tener una visión del “estado de salud” general
de la fase. Por ejemplo, podría parecer que la
fase está progresando bien, en el sentido de que
los productos se están completando de acuerdo
con el cronograma. Sin embargo, el Registro de
122 | Progreso
Cuestiones podría revelar que hay una cantidad
creciente de cuestiones que no se están resolviendo
y que podrían ser causa de preocupación. Del
mismo modo, una gran cantidad de elementos
pendientes relativos a un producto en el Registro
de Calidad podría indicar cuestiones de diseño con
ese producto.
Los siguientes productos de gestión ayudan al
Project Manager a revisar el progreso:
■■ Archivo Diario constituye una herramienta útil
para registrar acciones. Las acciones del proyecto
pueden derivar de muchas fuentes, incluyendo
puntos de control, revisiones de calidad,
evaluaciones al final de fase o conversaciones
puntuales. Existe el peligro de que las acciones
“se pierdan” si solamente se registran en actas
de reuniones o informes sobre el progreso. Las
acciones pequeñas pueden ser simplemente
registradas en el Archivo Diario y marcadas
como completas cuando se hayan finalizado. Las
acciones que impliquen un esfuerzo importante
podrían tener que incorporarse al Plan de la
Fase. Si esas acciones no se pueden incorporar al
plan dentro de las tolerancias, se debe plantear
una cuestión para examinar su impacto sobre la
fase y el proyecto. El Archivo Diario también se
puede usar para registrar cuestiones informales
y otras notas u observaciones que no se registran
en ninguno de los otros registros o archivos. El
Archivo Diario es una manera útil de registrar
observaciones individuales que por sí mismas
pueden parecer insignificantes, pero que
combinadas podrían alertar al Project Manager
de una nueva cuestión o un nuevo riesgo
■■ Registro de Cuestiones contendrá información
sobre todas las cuestiones formales planteadas
durante el proyecto, que podrían adoptar
la forma de solicitudes de cambio, fuera de
especificación o problemas/asuntos. Revisar el
Registro de Cuestiones puede revelar nuevas
cuestiones acerca del progreso. Por ejemplo,
un aumento repentino en el número de
solicitudes de cambio o una cantidad creciente de
rectificaciones pendientes
■■ Informe sobre el Estado de los Productos
proporciona una imagen instantánea del estado
de los productos dentro del proyecto, la fase de
gestión o un área concreta del proyecto. Puede
revelar cuestiones acerca del progreso, ya que
muestra las fechas planificadas y reales de los
puntos principales en la producción, revisión y
aprobación de los productos que el plan debe
entregar. El Informe sobre el Estado de los
Productos deriva de las Fichas de Elementos de
Configuración
■■ Registro de Calidad un testimonio documental
de todas las actividades de calidad planificadas
e implementadas. El Registro de Calidad puede
revelar cuestiones acerca del progreso, ya que el
Project Manager puede evaluar si está pendiente
alguna actividad de calidad o si existe alguna
tendencia útil en los resultados de calidad. Por
ejemplo, una cantidad creciente de productos
no está pasando la revisión de calidad o hay
un incremento en el promedio de acciones de
revisión de calidad
■■ Registro de Riesgos un testimonio documental
de todos los riesgos identificados. El Project
Manager debe revisar el Registro de Riesgos
como parte de la revisión del estado de la fase.
Como los riesgos se basan en la incertidumbre, el
número de riesgos debe normalmente disminuir
a medida que el proyecto progresa y el nivel
de certidumbre aumenta. Se debe revisar el
Registro de Riesgos para determinar si los riesgos
agregados pueden tener un impacto sobre el
progreso del resto de la fase y el proyecto. Por
ejemplo, podría existir una gran cantidad de
riesgos con una proximidad similar en el tiempo,
lo que indicaría un período en el que el progreso
se podría ver afectado.
Técnicas de evaluación del progreso
Medir el progreso de una fase de gestión implica
mirar hacia atrás, comparando el progreso
conseguido con los planes, y hacia adelante,
para ver qué debe ser aún completado, con qué
calendario y con qué recursos. Existen muchas
técnicas disponibles para medir el progreso del
proyecto, incluyendo:
■■ Cuadro de hitos Este consiste en un gráfico
que muestra los hitos principales de una
fase, tanto planificados como reales
■■ Curva en forma de S Esta consiste en
un gráfico que muestra cifras reales
acumulativas (por ejemplo, costes u horas),
mostradas en comparación con el calendario.
La curva tiene normalmente la forma de
la letra “S”, lo que refleja el hecho de que
un proyecto normalmente consume menos
recursos y costes al principio y al final del

proyecto, y más en las etapas intermedias.
Cuanto más inclinada sea la curva, más
recursos serán necesarios. Cuando se
muestran cifras planificadas y reales en el
mismo gráfico, esto se puede usar para
identificar posibles gastos excesivos o áreas
en las que se prevea que se podrían exceder
las tolerancias
■■ Gestión del valor ganado Esta es una
técnica para medir el rendimiento del
alcance, del cronograma y de los costes en
comparación con los planes, comparando los
productos completados y el coste y tiempo
reales con sus respectivas estimaciones
de costes y de tiempo. El enfoque de
planificación basada en el producto de
PRINCE2 proporciona los prerrequisitos
necesarios para la gestión del valor ganado.
10.3.3.3 Registrar e informar sobre las
lecciones
Los siguientes productos de gestión se utilizan para
registrar e informar sobre las lecciones cuando se
revisa el progreso:
■■ Archivo sobre las Lecciones Uno de los
principios de un proyecto de PRINCE2 es que
el equipo de gestión del proyecto aprenda
de la experiencia, lo que significa que se
buscan, registran y accionan lecciones en todo
momento. A menudo, es durante la revisión
del progreso cuando se identifican lecciones.
Las lecciones pueden incluir información
sobre procesos, productos, técnicas o
procedimientos de gestión o especializados
que o bien contribuyeron a los logros del
proyecto o bien causaron un problema. Por
ejemplo, el rendimiento del equipo de gestión
del proyecto, el éxito de adaptar PRINCE2
al proyecto o el análisis de estadísticas y
mediciones de calidad
■■ Informe sobre las Lecciones Aunque pueden
identificarse y registrarse lecciones durante un
proyecto, aprender lecciones requiere tomar
medidas para implementar mejoras. Estas
acciones pueden ser de aplicación al proyecto
actual, en cuyo caso se deben incorporar en los
planes y Paquetes de Trabajo correspondientes,
o podrían ser aplicables a proyectos diferentes.
Si una lección es importante y es aplicable a
futuros proyectos, se debe incluir en el Informe
sobre las Lecciones. Es importante tener en
Progreso | 123
cuenta que las acciones para aprender lecciones
se pueden llevar a cabo, y el Informe sobre
las Lecciones puede ser creado, en cualquier
momento que sea adecuado durante un
proyecto. Sin embargo, se debe elaborar como
mínimo un Informe sobre las Lecciones durante
el proceso del Cierre de un Proyecto.
10.3.3.4 Informar sobre el progreso
La frecuencia de los informes debe reflejar el nivel
de control requerido y es probable que este varíe
durante el proyecto. Por ejemplo:
■■ Durante la fase de diseño podría ser necesario
un control menos frecuente que durante las
fases de gestión posteriores
■■ Si el equipo tiene mucha experiencia, podría ser
adecuada una menor frecuencia de informes,
mientras que, para un equipo sin experiencia, el
Project Manager podría querer que se aumente
la frecuencia de los informes hasta que se
haya desarrollado suficiente confianza en la
capacidad del equipo.
Los siguientes productos de gestión se utilizan para
la informar sobre el progreso:
■■ Informe del Punto de Control El Team Manager
lo elaborará para proporcionar al Project
Manager información sobre el progreso en
comparación con el Paquete de Trabajo. El
Paquete de Trabajo incluirá la frecuencia con
la que se requieren Informes del Punto de
Control. El Project Manager reunirá los Informes
del Punto de Control y los usará como parte de
la evaluación del progreso a la hora de revisar
el estado de la fase
■■ Informe de Desarrollo El Project Manager
elabora este informe sobre el progreso de la
fase de gestión para la Junta de Proyecto. La
Junta de Proyecto determinará la frecuencia con
la que se requieren los Informes de Desarrollo
para todo el proyecto, o fase por fase, y la
documentará en la Estrategia de Gestión de la
Comunicación. El Informe de Desarrollo permite
a los miembros de la Junta de Proyecto realizar
gestión por excepción entre evaluaciones al
final de fase, ya que tienen conocimiento de las
tolerancias acordadas con el Project Manager en
el Plan de la Fase. El Informe de Desarrollo debe
confirmar que se está realizando un progreso
dentro de estas tolerancias y debe proporcionar
una alerta anticipada de posibles problemas
que puedan requerir acciones. Como parte de
124 | Progreso

la Estrategia de Gestión de la Comunicación, la o solicitar más tiempo para considerar o

Junta de Proyecto puede solicitar que se envíen rechazar las recomendaciones del Informe de
copias del Informe de Desarrollo a otras partes Cuestiones. Si se solicita un Plan de Excepción,
interesadas, externas al proyecto. La Junta la Junta de Proyecto llevará a cabo una
de Proyecto también remitirá el Informe de evaluación de excepción, similar a la evaluación
Desarrollo (o un resumen de éste) a la gerencia al final de fase, para revisar y aprobar el Plan
corporativa o del programa de Excepción
■■ Informe al Final de Fase Este es elaborado ■■ Excepciones a nivel de proyecto Si el
por el Project Manager hacia el final de cada pronóstico es que se van a exceder las
fase de gestión, proporcionando a la Junta de tolerancias del proyecto, la Junta de Proyecto
Proyecto la información sobre el progreso hasta ya no cuenta con la autoridad para gestionar
la fecha, la situación del proyecto en general y el proyecto y debe remitir el tema a la gerencia
(junto al Plan de la Fase) información suficiente corporativa o del programa, para que tome una
para solicitar una decisión de la Junta de decisión. La Junta de Proyecto podría solicitar
Proyecto sobre qué hacer a continuación con el al Project Manager que elabore un Plan de
proyecto Excepción para el proyecto.
■■ Informe al Final de Proyecto Este es elaborado
Véase el Capítulo 9 para más información sobre los
por el Project Manager hacia el final del procedimientos de control de cambios y cuestiones.
proyecto, durante el proceso del Cierre de un
Proyecto, y la Junta de Proyecto lo utiliza para
evaluar el proyecto y autorizar el cierre. 10.4 Responsabilidades
La Tabla 10.2 resume las responsabilidades
10.3.4 Presentación de excepciones
relacionadas con la temática del Progreso.
El resultado de revisar el progreso es una decisión Véase el Apéndice C para más información sobre
sobre si el Paquete de Trabajo, el Plan de la Fase los roles del equipo de gestión del proyecto y sus
o el Plan de Proyecto continúan, o se prevé que responsabilidades asociadas.
continuarán, dentro de las tolerancias acordadas:
■■ Excepciones a nivel de Paquete de Trabajo
Habiéndose acordado las tolerancias para el
Paquete de Trabajo con el Team Manager, se
debe mantener informado al Project Manager
sobre el progreso mediante Informes del
Punto de Control regulares. Si se prevé que un
Paquete de Trabajo va a exceder sus tolerancias,
el Team Manager debe informar al Project
Manager planteando una cuestión. El Project
Manager asesorará sobre las rectificaciones que
puedan ser necesarias
■■ Excepciones a nivel de fase Si se prevé
que la fase va a exceder sus tolerancias, el
Project Manager debe elaborar un Informe
de Cuestiones para registrar y analizar
la información sobre la desviación y a
continuación debe proporcionar un Informe
de Excepción a la Junta de Proyecto. En base
a la información de este informe, la Junta de
Proyecto podría solicitar que el Project Manager
elabore un Plan de Excepción que sustituya
al plan que se prevé que va a exceder la
tolerancia. La Junta de Proyecto también puede
eliminar la causa, aceptar y ajustar la tolerancia,
 Progreso | 125

Tabla 10.2 Responsabilidades relacionadas con la temática de Progreso

Rol Responsabilidades
Gerencia corporativa o del Proporcionar las tolerancias del proyecto y documentarlas en el mandato de proyecto.
programa
Tomar decisiones sobre Planes de Excepción cuando se prevea que se van a exceder las
tolerancias a nivel de proyecto.

Ejecutivo Proporcionar las tolerancias a nivel de fase.

Asegurarse de que el progreso hacia el resultado final siga siendo coherente desde el punto
de vista comercial.

Tomar decisiones sobre Planes de Excepción cuando se prevea que se van a exceder las
tolerancias a nivel de fase.

Recomendar acciones futuras en el proyecto a la gerencia corporativa o del programa, si se

prevé que se va a exceder la tolerancia del proyecto.

Usuario Principal Asegurarse de que el progreso hacia el resultado final siga siendo coherente desde el punto
de vista del usuario.

Proveedor Principal Asegurarse de que el progreso hacia el resultado final siga siendo coherente desde el punto
de vista del proveedor.

Project Manager Autorizar Paquetes de Trabajo.

Hacer un seguimiento del progreso en comparación con los Planes de Fase.
Elaborar Informes de Desarrollo, Informes al Final de Fase, Informes sobre las Lecciones y el
Informe al Final de Proyecto.
Elaborar Informes de Excepción para la Junta de Proyecto cuando se prevea que se van a
exceder las tolerancias a nivel de fase.

Mantener los registros y archivos del proyecto.

Team Manager Acordar Paquetes de Trabajo con el Project Manager.
Informar al Apoyo al Proyecto de las actividades de calidad completadas.
Elaborar Informes del Punto de Control.
Notificar al Project Manager cualquier desviación prevista respecto de las tolerancias del
Paquete de Trabajo.
Garantía del Proyecto Verificar el Business Case, comparándolo con acontecimientos externos y con el progreso del
proyecto.
Verificar los cambios en el Plan de Proyecto para determinar si hay un impacto en las
necesidades comerciales o en el Business Case.

Confirmar el progreso de la fase y del proyecto, comparándolo con las tolerancias acordadas.
Apoyo al Proyecto Ayudar en la elaboración de informes.
Contribuir con conocimientos sobre herramientas especializadas (por ejemplo, herramientas de
planificación y control).
Numerar, registrar, almacenar y distribuir Informes de Cuestiones e Informes de Excepción.
Ayudar al Project Manager a mantener el Registro de Cuestiones y el Registro de Riesgos.
Mantener el Registro de Calidad en nombre del Project Manager.
 11
Introducción a
los procesos
11 Introducción a los procesos
11.1 Los procesos de PRINCE2
PRINCE2 es un enfoque de gestión de proyectos
basado en procesos. Un proceso es un conjunto
estructurado de actividades diseñadas para lograr
un objetivo específico. Toma uno o más aportes
definidos y los convierte en resultados definidos.
En PRINCE2 existen siete procesos, que
proporcionan el conjunto de actividades necesarias
para dirigir, gestionar y entregar un proyecto con
éxito.
La Figura 11.1 muestra cómo se usa cada proceso
durante la vida de un proyecto.
Pre-proyecto Fase de inicio
Dirección
SU
SB
Gestión
IP
Entrega
Leyenda
SU = Puesta en Marcha de un Proyecto
IP = Inicio de un Proyecto
SB = Gestión de Límites de Fase
CP = Cierre de un Proyecto
Figura 11.1 Los procesos de PRINCE2
11.2 El trayecto de PRINCE2
La Junta de Proyecto establece la dirección y
toma las decisiones principales durante la vida del
proyecto. Las actividades de la Junta de Proyecto
se cubren en el proceso de la Dirección de un
Proyecto (véase el Capítulo 13), que va desde las
consideraciones previas al proyecto hasta la fase
final, incluyendo esta última.
11.2.1 Pre-proyecto
Al principio, alguien tiene una idea o una
necesidad. Esto puede derivar de nuevos objetivos
comerciales o ser una respuesta a presiones de la
competencia, a cambios en la legislación o a una
recomendación en un informe o una auditoría.
El desencadenante para el proyecto puede ser
prácticamente cualquier cosa. En PRINCE2, este
desencadenante recibe el nombre de mandato de
proyecto. La organización que encarga el proyecto
(gerencia corporativa o del programa) proporciona
Fase(s) de entrega Fase final
subsiguiente(s) de entrega
Dirección de un Proyecto
SB CP
Control de una Fase Control de una Fase
Gestión de la Entrega Gestión de la Entrega
de Productos de Productos
Nota
• Tanto los niveles de dirección como de gestión utilizan la Puesta
en Marcha de un Proyecto.
• Debería haber como mínimo dos fases de gestión, la primera de
las cuales es la fase de inicio.
• La Gestión de Límites de Fase se utiliza por primera vez al final
de la fase de inicio y se repite al final de cada fase subsiguiente,
salvo la fase final. También se utiliza para preparar Planes de Excepción,
lo cual se puede hacer en cualquier momento, incluyendo durante la
fase final.
• Opcionalmente, para los inicios complejos o prolongados, Control de
una Fase y Gestión de la Entrega de Productos se pueden utilizar para
gestionar la fase de inicio.
130 | Introducción a los procesos
el mandato de proyecto. Su forma puede variar
desde instrucciones verbales hasta una definición
de proyecto bien definida y justificada.
Antes de llevar a cabo la actividad para determinar
plenamente el alcance del proyecto, es importante
verificar que el proyecto merece la pena y es
viable. Esas actividades se cubren en el proceso
de la Puesta en Marcha de un Proyecto (véase el
Capítulo 12), que culmina con la elaboración de un
Expediente del Proyecto y un Plan de la Fase para
el inicio del proyecto.
La Junta de Proyecto revisa el Expediente
del Proyecto y decide si inicia el proyecto,
estableciendo los niveles de autoridad que se
delegarán al Project Manager para la fase de inicio.
11.2.2 Fase de inicio
Cuando ya existe una decisión de seguir adelante
con el proyecto, éste necesita ser planificado
detalladamente. Se tiene que obtener financiación
y se deben definir controles para asegurarse de que
el proyecto proceda de acuerdo con la voluntad
de aquellas personas que van a pagar el proyecto
y aquellos que harán uso de lo que el proyecto
vaya a entregar. La planificación detallada, el
establecimiento de las estrategias y controles de
gestión del proyecto, el desarrollo de un Business
Case sólido y un medio para revisar los beneficios,
se cubren en el proceso del Inicio de un Proyecto
(véase el Capítulo 14). Además, durante la fase de
inicio, el proceso de la Gestión de los Límites de
Fase (véase el Capítulo 17) se utiliza para planificar
detalladamente la siguiente fase.
La fase de inicio culmina con la elaboración de
la Documentación de Inicio del Proyecto, que es
revisada por la Junta de Proyecto para decidir
si se autoriza el proyecto. Como es probable
que el contenido de la Documentación de
Inicio del Proyecto cambie durante el proyecto
(mediante control de cambios), esta versión de la
Documentación de Inicio de Proyecto se conserva
como aporte para las revisiones de rendimiento
posteriores.
11.2.3 Fases de entrega posteriores
La Junta de Proyecto delega el control diario
al Project Manager, fase por fase. El Project
Manager necesita asignar el trabajo que se
tiene que llevar a cabo, asegurarse de que los
resultados de ese trabajo (productos) cumplan
con las especificaciones pertinentes, y obtener la
aprobación apropiada cuando sea necesario. El
Project Manager también tiene que asegurarse de
que el progreso esté en línea con el plan aprobado
y que las previsiones de las metas de rendimiento
del proyecto estén dentro de las tolerancias
acordadas. El Project Manager se asegura de
que se mantenga un conjunto de testimonios
documentales del proyecto (Archivo Diario,
Archivo sobre las Lecciones, Registro de Cuestiones,
Registro de Riesgos, Registro de Calidad y Fichas
de Elementos de Configuración), para ayudar al
control del progreso. El Project Manager informa
a la Junta de Proyecto sobre el progreso mediante
Informes de Desarrollo regulares. Las actividades
para controlar cada fase se cubren en el proceso
del Control de una Fase (véase el Capítulo 15).
En el proceso de la Gestión de la Entrega de
Productos (véase el Capítulo 16), el/los Team
Manager(s) o miembros del equipo ejecutan
Paquetes de Trabajo asignados (que entregarán
uno o más productos) y mantienen al Project
Manager informado sobre el progreso mediante
Informes del Punto de Control.
Hacia el final de cada fase de gestión, el Project
Manager solicita permiso para proceder a la
siguiente fase, informando sobre el rendimiento
de la fase, proporcionando una actualización
del Business Case y planificando detalladamente
la siguiente fase de gestión. El Project Manager
proporciona la información que la Junta de
Proyecto necesita para evaluar la viabilidad
continua del proyecto y para tomar una decisión
sobre la autorización de la fase de gestión
siguiente. Las actividades para gestionar cada
límite de fase se cubren en el proceso de la Gestión
de los Límites de Fase (véase el Capítulo 17).
11.2.4 Fase de entrega final
Como un proyecto es algo temporal, durante
la fase final (cuando el Project Manager haya
obtenido la aprobación para todos los productos
del proyecto) llega el momento de cerrar el
proyecto. La Junta de Proyecto tiene que concluir
que los destinatarios de los productos del proyecto
están en situación de adquirir su propiedad y
utilizarlos de modo continuo. Si éste es el caso,
los productos pueden entrar en su vida operativa
y se puede cerrar el proyecto. La documentación
del proyecto se debe poner en orden y archivar,
el proyecto se debe evaluar para comparar su
rendimiento con su plan original y los recursos
asignados al proyecto tienen que ser liberados.
Las actividades de cierre incluyen planificar la
realización de revisiones de beneficios después del
 Introducción a los procesos | 131

proyecto para aquellos beneficios que solamente 11.3 El modelo de procesos de

se pueden evaluar después que los productos PRINCE2
hayan sido utilizados (y, por lo tanto, después del
cierre del proyecto). Las actividades para cerrar un El modelo de procesos de PRINCE2 se muestra en la
proyecto se cubren en el proceso del Cierre de un Figura 11.2.
Proyecto (véase el Capítulo 18). Los procesos van en línea con los niveles de gestión
corporativos o del programa: dirección, gestión y
entrega. Se muestran los desencadenantes entre
los distintos procesos.
Corporativa o
del programa

Asesoramiento y
Mandato de proyecto decisiones
corporativas

Notificación de Solicitud de
Notificación Notificación
autorización asesoramiento de la
de inicio de cierre
del proyecto Junta de Proyecto

Dirección de un Proyecto
Dirección

Autorización
de fase

Autoridad para Solicitud de Plan de Excepción Asesoramiento de Cierre

iniciar un proyecto Plan de Excepción aprobado la Junta de Proyecto prematuro
Puesta en Marcha de un Proyecto

Solicitud de aprobación
del Plan de Excepción

Solicitud de aprobación
Solicitud de inicio Solicitud de entrega del Plan de Recomendación
de un proyecto de un proyecto la Fase siguiente de cierre

Inicio de Gestión de los Cierre de

un Proyecto Límites de Fase un Proyecto
Gestión

Excepción
planteada

Solicitud de
Se acerca el asesoramiento Se acerca el
límite de fase final del proyecto

Control de una Fase

Autoridad para entregar

un Paquete de Trabajo

Paquete de Trabajo
Completado
Entrega

Gestión de la Entrega de Productos

Notas:

Nota 1: al final de la fase de inicio, se utiliza el proceso del Inicio de un Proyecto para solicitar la aprobación de la Junta de
Proyecto para iniciar el proyecto (con la presentación de la Documentación de Inicio del Proyecto) y paralelamente se utiliza
el proceso de la Gestión de los Límites de Fase para solicitar que la Junta de Proyecto apruebe el Plan de la Fase para la
segunda fase de gestión.

Nota 2: las actividades de cierre se planifican y se aprueban como parte de la aprobación de la fase para la fase final; por lo
tanto, el proceso del Cierre de un Proyecto tiene lugar en la fase final.

Figura 11.2 Modelo de procesos de PRINCE2

132 | Introducción a los procesos

11.4 Estructura de los capítulos de 11.4.4 Actividades

los procesos
Cada proceso de PRINCE2 se describe utilizando la
siguiente estructura y formato.
11.4.1 Propósito
Esta sección describe la razón para el proceso.
11.4.2 Objetivo
Esta sección describe los objetivos específicos que el
proceso debe alcanzar.
11.4.3 Contexto
Esta sección pone a cada proceso en contexto
con los otros procesos y actividades que están
en desarrollo dentro del proyecto y con los de la
gerencia corporativa o del programa.
Los procesos de PRINCE2 incluyen un conjunto de
actividades, que pueden transcurrir en serie o en
paralelo. Las actividades de PRINCE2 incluyen un
conjunto de acciones recomendadas diseñadas
para lograr un resultado concreto.
La relación entre procesos, actividades y acciones se
muestra en la Figura 11.3.
Para cada actividad se facilita un diagrama que
muestra los aportes y resultados, incluyendo
aquellos productos que esa actividad crea o
actualiza. Se describen las acciones recomendadas
que se deben llevar a cabo para lograr los objetivos
de la actividad.
Cada actividad concluye con una tabla que muestra
las responsabilidades para cada producto creado o
actualizado durante la actividad, como se ilustra en
la Tabla 11.1.

Cada uno incluye

Procesos

Actividades Cada una incluye

Acciones
recomendadas
Figura 11.3 Relación entre procesos, actividades y acciones

Tabla 11.1 Un ejemplo de tabla de responsabilidades

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción

Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Usuario Principal

Project Manager

Team Manager
Ejecutivo

Producto Acción
Plan de la Fase Crear (A) (A) (A) P R A.22
 Introducción a los procesos | 133

Tabla 11.2 Leyenda para los diagramas de procesos

Símbolo Leyenda

Éste es un proceso de PRINCE2.

Puesta en Marcha
de un Proyecto

Autorizar Ésta es una actividad. Cada proceso incluye una serie de actividades.
el inicio

Éste es un evento o una decisión que desencadena otro proceso o se utiliza

para notificar a la gestión corporativa o del programa. La flecha muestra el
Solicitud de proceso que es desencadenado por el evento.
Plan de Excepción
Los desencadenantes dobles indican dónde hay desencadenantes
alternativos de un proceso a otro (por ej., una solicitud de aprobación del
Plan de la Fase siguiente o una solicitud de aprobación de un
Plan de Excepción).
Rectificación
Aquellos con líneas de puntos son desencadenantes internos a un proceso
(por ej. rectificación es un desencadenante de una actividad a otra en el
proceso del Control de una Fase).

Business Case Éstos son productos de gestión que se crean o se actualizan con las
actividades de un proceso.
Aquellos con líneas enteras son productos de gestión definidos según los
Contenidos Básicos de las Descripciónes de Producto en el Apéndice A.
Aquellos con líneas de puntos son componentes de un producto de
Acciones a realizar
recomendadas gestión o son productos de gestión no definidos para los cuales PRINCE2
no requiere criterios de calidad o de composición específicos.

Téngase en cuenta que los productos de gestión

creados durante un proceso podrían ser aprobados
en otro (por ejemplo, un Plan de la Fase se crea
en el proceso de la Gestión de los Límites de Fase
pero se aprueba en el proceso de la Dirección de
un Proyecto). Sin embargo, se muestra el conjunto
completo de responsabilidades y se identifican
aquellas que están cubiertas por otro proceso
mostrándolas entre paréntesis, por ejemplo, (A).
 12
Puesta en Marcha
de un Proyecto
12 Puesta en Marcha de un Proyecto

12.1 Propósito 12.2 Objetivo

El propósito del proceso de la Puesta en Marcha
de un Proyecto es asegurar que se hayan
implementado los prerrequisitos para el Inicio de un
Proyecto al responder a la pregunta ¿tenemos un
proyecto viable y que vale la pena?
No se debería hacer nada hasta que se haya
definido una cantidad de información de base
suficiente para tomar decisiones racionales para
autorizar el encargo del proyecto, hasta que
se hayan financiado y asignado los roles y las
responsabilidades principales y haya disponibles
fundamentos para una planificación detallada.
El propósito del proceso de la Puesta en Marcha
de un Proyecto consiste tanto en impedir que
se inicien proyectos mal concebidos así como en
aprobar el inicio de proyectos viables. Como tal,
la Puesta en Marcha de un Proyecto es un proceso
menos engorroso que el proceso más detallado y
exhaustivo del Inicio de un Proyecto. La finalidad es
hacer lo mínimo necesario a fin de decidir si vale la
pena siquiera iniciar el proyecto.
El objetivo del proceso de la Puesta en Marcha de
un Proyecto es asegurar que:
■■ Haya una justificación comercial para iniciar el
proyecto (documentada en un Business Case
preliminar)
■■ Existan todas las autorizaciones necesarias para
iniciar el proyecto
■■ Haya disponible suficiente información para
definir y confirmar el alcance del proyecto (bajo
la forma de un Expediente del Proyecto)
■■ Se evalúen las diversas maneras en que el
proyecto se puede entregar y se seleccione un
enfoque del proyecto
■■ Se nombren personas que realizarán el trabajo
requerido durante el inicio del proyecto y/o
que asumirán luego los roles fundamentales de
gestión del proyecto
■■ Se planifique el trabajo requerido para el inicio
del proyecto (documentado en un Plan de la
Fase)

Gestión
Mandato de proyecto
corporativa o
del programa

Dirección de
un Proyecto

Nombrar al Ejecutivo
y
al Project Manager

Registrar Diseñar y nombrar al

equipo de gestión
lecciones anteriores
del proyecto

Preparar el Seleccionar el enfoque

del proyecto y preparar
Business Case preliminar el Expediente del Proyecto

Solicitud de
Planificar
inicio de un proyecto
Puesta en Marcha de un Proyecto la fase de inicio

Figura 12.1 Visión general de la Puesta en Marcha de un Proyecto

138 | Puesta en Marcha de un Proyecto
■■ No se pierda tiempo iniciando un proyecto
en base a suposiciones poco sólidas sobre
el alcance, los calendarios, los criterios de
aceptación y las restricciones del proyecto.
12.3 Contexto
Los proyectos se pueden identificar de diversas
maneras y, por ende, pueden tener gran variedad
de información disponible en el momento
de la puesta en marcha. PRINCE2 llama al
desencadenante del proyecto el mandato de
proyecto, que procede de la autoridad responsable
que encarga el proyecto – normalmente la gestión
corporativa o del programa. El término mandato de
proyecto se aplica a cualquier información que se
utiliza para activar el proyecto, sea ésta un estudio
de viabilidad o la recepción de una “solicitud
de propuesta” en un entorno de proveedor. El
mandato de proyecto debería indicar el cometido
del proyecto y debería contener suficiente
información para identificar al menos al futuro
Ejecutivo de la Junta de Proyecto. El mandato se
perfecciona para desarrollar el Expediente del
Proyecto.
Se debe dar a la Junta de Proyecto suficiente
información para que tome la decisión de iniciar
el proyecto. El Expediente del Proyecto se prepara
para este propósito.
El esfuerzo necesario para la Puesta en Marcha de
un Proyecto variará enormemente de un proyecto
a otro. Si el proyecto es parte de un programa, el
propio programa debería proveer el Expediente
del Proyecto y nombrará a algunos, si no todos, los
miembros de la Junta de Proyecto, eliminando así
gran parte del trabajo requerido en este proceso.
En tales casos, el Project Manager debería validar
lo que procede del programa y, si es necesario,
recomendar modificaciones.
La preparación del Business Case preliminar y
del Expediente del Proyecto (que son actividades
paralelas e iterativas) requieren interacción y
consultas regulares y frecuentes entre el Project
Manager, los miembros de la Junta de Proyecto
y otras parte interesadas. Cuánto más tiempo se
dedique a registrar con claridad las exigencias
durante el proceso de la Puesta en Marcha de
un Proyecto, más tiempo se ahorrará durante
la entrega del proyecto al prevenir cuestiones,
excepciones y replanificación.
El contenido del Expediente del Proyecto se
extiende y se perfeccoina luego para formar la
Documentación de Inicio del Proyecto a través del
proceso del Inicio de un Proyecto.
12.4 Actividades
Es probable que las actividades dentro del proceso
de la Puesta en Marcha de un Proyecto sean
compartidas entre la gestión corporativa o del
programa, el Ejecutivo y el Project Manager, e
incluyen:
■■ Nombrar el Ejecutivo y el Project Manager
■■ Registrar lecciones anteriores
■■ Diseñar y nombrar el equipo de gestión del
proyecto
■■ Preparar el Business Case preliminar
■■ Seleccionar el enfoque del proyecto y elaborar
el Expediente del Proyecto
■■ Planificar la fase de inicio.
12.4.1 Nombrar el Ejecutivo y el
Project Manager
Para que se haga cualquier cosa en el proyecto
es necesario que haya una persona encargada
de tomar decisiones, que cuente con autoridad
apropiada – el Ejecutivo – y que represente
los intereses de la o las partes con intereses
comerciales. El nombramiento del Ejecutivo es
un prerrequisito para asegurar que el proyecto
esté justificado. El nombramiento de un Project
Manager permite la gestión diaria del proyecto en
nombre del Ejecutivo. El Ejecutivo podría necesitar
consultar a la gestión corporativa o del programa
y obtener su aprobación al nombrar un Project
Manager.
La figura 12.2 muestra los aportes y resultados
relativos a esta actividad. Para más información
sobre la organización del proyecto, véase el
Capítulo 5.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el mandato de proyecto y comprobar su
comprensión
■■ Nombrar al Ejecutivo (el nombramiento es
hecho por la organización que encarga el
proyecto – típicamente la gestión corporativa o
del programa):
●● Establecer las responsabilidades para el
Ejecutivo
 Puesta en Marcha de un Proyecto | 139

Nombrar al Ejecutivo (Parte del)

Mandato de proyecto y Expediente del Proyecto
al Project Manager

Descripción del rol

Crear del Ejecutivo

Descripción del rol

Crear del Project Manager

Ejecutivo
nombrado

Project Manager
nombrado

Crear
Archivo Diario

Figura 12.2 Resumen de actividades para nombrar el Ejecutivo y el Project Manager

●●Preparar la descripción del rol para el Calcular el tiempo y el esfuerzo requeridos

●●
Ejecutivo en base a la descripción del rol en para el rol de Project Manager (esto se
el Apéndice C perfeccionará más adelante)
●● Calcular el tiempo y el esfuerzo ●● Confirmar la disponibilidad de la persona
requeridos para el rol de Ejecutivo (esto se seleccionada, su aceptación del rol y su
perfeccionará más adelante) compromiso a realizarlo
●● Identificar candidatos para el rol de Ejecutivo ●● Nombrar a la persona seleccionada al rol de
entre las partes interesadas al proyecto y Project Manager
seleccionar la persona más apropiada para el ●● Confirmar el nombramiento con la gestión
rol corporativa o del programa
●● Confirmar la disponibilidad de la persona ■■ Crear el Archivo Diario como un depósito para
seleccionada, su aceptación del rol y su información sobre el proyecto que todavía no
compromiso a realizarlo ha sido registrada en otro lugar.
●● Nombrar a la persona seleccionada al rol de
La Tabla 12.1 muestra las responsabilidades para
Ejecutivo
esta actividad.
■■ El Ejecutivo será responsable de nombrar al
Project Manager:
●● Establecer las responsabilidades para el
Project Manager
●● Preparar una descripción del rol para el
Project Manager en base a la descripción
del rol en el Apéndice C y obtener el
consentimiento de la gestión corporativa o
del programa
●● Identificar candidatos para el rol de Project
Manager y seleccionar la persona más
apropiada
140 | Puesta en Marcha de un Proyecto
Tabla 12.1 Responsabilidades para nombrar el Ejecutivo y el Project Manager
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Mandato de proyecto Proporcionar
Descripción del rol del Ejecutivo Crear
Ejecutivo nombrado Confirmar
Descripción del rol del Project Manager Crear
Project Manager nombrado Confirmar
Archivo Diario Crear
12.4.2 Registrar lecciones anteriores
La gestión corporativa o del programa, las
organizaciones externas y las experiencias de
otros proyectos pueden aportar lecciones sobre
las debilidades o fortalezas de los procesos,
procedimientos, técnicas o herramientas que han
sido utilizados, cuándo se utilizaron, cómo se
utilizaron y quién los utilizó.
El diseño del equipo de gestión del proyecto,
el Business Case preliminar, el contenido del
Expediente del Proyecto y el Plan de la Fase de
Inicio podrían estar influenciados por las lecciones
de proyectos anteriores.
Podría ser útil realizar un taller de trabajo a fin de
registrar las lecciones pertinentes. Los asistentes
podrían incluir cualquier parte interesada y gente
que ha trabajado en proyectos similares anteriores.
Si la organización no ha realizado este tipo de
proyecto con anterioridad, podría ser práctico
Informes sobre las Registrar
lecciones anteriores lecciones anteriores
Figura 12.3 Resumen de actividades para registrar lecciones anteriores
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
P
P
P
A P
A P
P A.2
incluir personas externas a la organización que
cuenten con experiencia pertinente.
Al pasar de la visión general en la Puesta en
Marcha de un Proyecto a la visión detallada en el
Inicio de un Proyecto y a una visión actualizada
en la Gestión de los Límites de Fase, podría ser
necesario mirar más allá del Archivo sobre las
Lecciones, repitiendo esta actividad a fin de
registrar cualquier otra lección externa pertinente.
La figura 12.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Crear el Archivo sobre las Lecciones
■■ Revisar los Informes sobre las Lecciones de
proyectos anteriores similares para identificar
las lecciones que se pueden aplicar a este
proyecto. Éstas podrían incluir, por ejemplo,
resultados de auditorías y revisiones del
proyecto
Crear Archivo sobre
las Lecciones
 Puesta en Marcha de un Proyecto | 141

Tabla 12.2 Responsabilidades para registrar las lecciones anteriores

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción

Archivo sobre las Lecciones Crear R P A.1

■■ Revisar cualquier lección de la gestión 12.4.3 Diseñar y nombrar el equipo de

corporativa, de la gestión del programa y de
organizaciones externas
■■ Consultar a personas o equipos con experiencia
previa en proyectos similares
■■ Si es apropiado, dejar constancia de cualquier
lección identificada en el Archivo sobre las
Lecciones.
La Tabla 12.2 muestra las responsabilidades para
esta actividad.
gestión del proyecto
El proyecto necesita personas apropiadas, con la
autoridad, responsabilidad y los conocimientos para
tomar decisiones oportunas. El equipo de gestión
del proyecto necesita reflejar los intereses de todas
las partes que participarán, incluyendo los intereses
comerciales, de usuarios y proveedores.
Para que un proyecto esté bien gestionado es
esencial que cada persona que participa en su
gestión comprenda y acuerde quién es responsable
ante quién de qué cosa, quién es responsable de
qué y cuáles son las dependencias y las líneas de
comunicación.

Archivo sobre las Diseñar y nombrar Actualizar

Lecciones al equipo de Archivo Diario
gestión del proyecto

(Parte del) (Parte del)

Expediente del Proyecto Expediente del Proyecto

Descripciones de roles
Descripción del del equipo de
rol del Ejecutivo gestión del proyecto
Crear

Descripción del rol Estructura del

equipo de gestión
del Project Manager del proyecto
Crear

Equipo de gestión
del proyecto nombrado

Figura 12.4 Resumen de actividades para diseñar y nombrar el equipo de gestión del proyecto
142 | Puesta en Marcha de un Proyecto
La figura 12.4 muestra los aportes y resultados
relativos a esta actividad. Para más detalles sobre la
organización del proyecto, véase el Capítulo 5.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Archivo sobre las Lecciones para
encontrar las lecciones relacionadas con la
estructura del equipo de gestión del proyecto
■■ Diseñar el equipo de gestión del proyecto
●● Preparar la estructura del equipo de gestión
del proyecto
●● Crear descripciones de roles para los roles
restantes de la Junta de Proyecto en base a
las descripciones de roles en el Apéndice C
●● Evaluar si es probable que uno o más
miembros de la Junta de Proyecto deleguen
algunas de sus responsabilidades de garantía
y crear la descripción del rol para Garantía
del Proyecto (donde corresponda) en base a
la descripción del rol en el Apéndice C
●● Considerar si es probable que se necesiten
diferentes personas como Team Manager,
o Managers, o si el Project Manager
desempeñará este rol. Si es apropiado, crear
descripciones de roles para el Team Manager,
o Managers, en base a la descripción del rol
en el Apéndice C
●● Considerar si el Project Manager
desempeñará el rol de Apoyo al Proyecto
o si se requerirá una o más personas
Tabla 12.3 Responsabilidades para diseñar y nombrar el equipo de gestión del proyecto
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto
Archivo Diario
Descripciones de roles del equipo de gestión del proyecto Crear
Estructura del equipo de gestión del proyecto Crear
Equipo de gestión del proyecto nombrado
diferentes. Si este rol se ha de delegar,
crear la descripción del rol para Apoyo al
Proyecto en base a la descripción del rol en
el Apéndice C
●● Confirmar las dependencias y las líneas de
comunicación dentro de las descripciones de
roles
■■ Nombrar al equipo de gestión del proyecto:
●● Calcular el tiempo y el esfuerzo requeridos
por cada uno de los roles identificados (esto
se perfeccionará más adelante)
●● Identificar candidatos para cada uno de
los roles y proponer a las personas más
apropiadas para ellos:
●● Quizás sea apropiado realizar un análisis
de las partes interesadas (véase la sección
5.3.5) a fin de identificar candidatos
apropiados para los roles
●● Es posible que los candidatos no se
conozcan en este momento, en cuyo caso
será necesario seleccionarlos más adelante
(véase la sección 14.4.5 y 17.4.1). Esto es
verdad en particular si los Team Managers
han de proceder de los subcontratistas
●● Considerar si los candidatos identificados
cuentan con las competencias requeridas
para el rol y, de no ser así, si se requiere
cualquier capacitación o apoyo (por ej.,
coaching)
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
Acción
Actualizar P A.2
A P
A P
Confirmar A P

Preparar el
Mandato de Business Case
proyecto preliminar
Archivo sobre las
Lecciones
Figura 12.5 Resumen de actividades para preparar el Business Case preliminar
●● Confirmar la disponibilidad de las personas
seleccionadas (si se sabe), su comprensión
y aceptación del rol y su compromiso a
realizarlo
●● Nombrar a la gente seleccionada a cada
uno de los roles identificados y confirmar el
nombramiento con la gestión corporativa o
del programa
■■ Si se identifica cualquier riesgo, añadirlo al
Archivo Diario.
La Tabla 12.3 muestra las responsabilidades para
esta actividad.
12.4.4 Preparar el Business Case
preliminar
Al establecer y, en particular, al ejecutar el proyecto
es muy fácil concentrarse en qué se está haciendo
y cómo se debe hacer, ignorando por qué es
necesario hacerlo. El Business Case explica por qué
vale la pena hacer el trabajo y, como tal, es un
elemento crucial del proyecto.
Si el proyecto es parte de un programa, el Business
Case podría haberse definido ya a nivel de
programa.
Dada la información disponible, es probable que el
Business Case preliminar sea sólo una perspectiva
de alto nivel en este momento. Proporciona
una base convenida para un Business Case más
exhaustivo desarrollado en el proceso del Inicio de
un Proyecto.
Puesta en Marcha de un Proyecto | 143
(Parte del)
Expediente del Proyecto
Business Case
(preliminar)
Crear
Descripción del
Producto del Proyecto
Crear
Archivo Diario
Actualizar
La figura 12.5 muestra los aportes y resultados
relativos a esta actividad. Para más información
sobre el Business Case, véase el Capítulo 4.
PRINCE2 recomienda las siguientes acciones:
■■ El Ejecutivo redactará el Business Case
preliminar en base a lo que se sabe en la
actualidad sobre el proyecto:
●● Comprender los objetivos del proyecto y las
razones para el mismo, según lo definido en
el mandato de proyecto
●● Comprender de qué manera el proyecto
contribuirá a los objetivos corporativos y/o
del programa
●● Comprender cómo se financiará el proyecto
●● Revisar el Archivo sobre las Lecciones para
encontrar lecciones relacionadas con la
justificación comercial
●● Comprobar si hay cualquier norma exigida
para el formato y la presentación del
Business Case (plantillas, métrica de costos,
etc.)
●● Preparar cualquier información general
pertinente, por ej. contratos, informes de
viabilidad, acuerdos de nivel de servicio, etc.
●● Si es necesario, solicitar que la gestión
corporativa o del programa apruebe el
Business Case preliminar
■■ El Project Manager consultará al Usuario
Principal y al Ejecutivo a fin de definir aquello
que el proyecto debe entregar y creará la
Descripción del Producto del Proyecto (véase el
Capítulo 6):
144 | Puesta en Marcha de un Proyecto
Tabla 12.4 Responsabilidades para preparar el Business Case preliminar
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Business Case preliminar Crear
Descripción del Producto del Proyecto Crear
Archivo Diario Actualizar
Registrar las expectativas de calidad del
●●
cliente
●● Registrar y convenir los criterios de
aceptación del proyecto
●● Comprobar la viabilidad de las exigencias de
los calendarios en el mandato de proyecto
o según las exigencias del Business Case
preliminar
●● Determinar cualquier hito principal
●● Registrar cualquier riesgo nuevo en el
Archivo Diario
■■ Revisar los riesgos registrados en el Archivo
Diario y resumir los riesgos principales que
afectan la viabilidad del proyecto en el Business
Case preliminar.
La Tabla 12.4 muestra las responsabilidades para
esta actividad.
12.4.5 Seleccionar el enfoque del
proyecto y elaborar el
Expediente del Proyecto
Antes de que pueda tener lugar cualquier
planificación del proyecto, se deberán tomar
decisiones sobre la manera en que se va a
enfocar el trabajo del proyecto. Por ejemplo,
¿se desarrollará la solución internamente o se
contratarán proveedores externos? ¿Será la
solución una modificación a un producto existente
o se construirá desde el principio? La solución, ¿se
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
A P R R R R A.3
(A) (A) (A) P R A.5
P A.2
basará en un producto comercial en existencia (a
menudo llamados COTS por las siglas en inglés
Commercial Off The Shelf) o en algo diseñado por
encargo?
La manera en que se ha de realizar el trabajo
dependerá de cualquier norma, práctica y
directriz del cliente o proveedor – por ejemplo,
cualquier ciclo de vida de desarrollo específico
que sea aplicable. Éstos se deberán registrar en el
Expediente del Proyecto como parte del enfoque
del proyecto, ya que influirán en las estrategias
del proyecto que se crearán en el proceso del
Inicio de un Proyecto. Además se asegura que haya
comprensión clara del enfoque del proyecto entre
el cliente y el proveedor y no se pone el proyecto
en peligro de ninguna manera.
Un Expediente del Proyecto convenido asegura que
el proyecto cuente con un punto de partida bien
definido y comprendido por todas sus partes.
La figura 12.6 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Evaluar las soluciones de entrega posibles y
decidir el enfoque del proyecto apropiado para
la entrega del producto del proyecto y el logro
del Business Case preliminar:
●● Revisar el Archivo sobre las Lecciones para
encontrar las lecciones relacionadas con el
enfoque del proyecto

(Parte del)
Expediente del Proyecto
Descripción del
Producto del Proyecto
Business Case
(preliminar)
Descripción del
rol del Ejecutivo
Descripción del
rol del Project Manager
Descripciones de roles
del equipo de gestión
del proyecto
Estructura del equipo
de gestión del proyecto
Archivo sobre las Lecciones
Figura 12.6 Resumen de actividades para seleccionar el enfoque del proyecto y elaborar el Expediente del Proyecto
●● Considerar cualquier estrategia corporativa
o del programa que sea pertinente y poner
el proyecto en contexto con cualquier
otro trabajo o iniciativas corporativas
al establecer dependencias externas y
prerrequisitos
●● Considerar cualquier norma o práctica
corporativa o del programa que se debería
aplicar (en un contexto de cliente/proveedor
comercial es probable que haya diferentes
normas y prácticas que será necesario tener
en cuenta)
●● Considerar el punto de vista actual sobre
la provisión de soluciones dentro de los
sectores de la industria y las áreas de
competencias especializadas en cuestión
(incluyendo cualquier opción técnica para el
ciclo de vida de desarrollo del producto del
proyecto)
●● Definir el entorno operativo en el cual
la solución debe encajar (incluyendo las
consecuencias y las restricciones operativas
o de mantenimiento) y la manera en que el
producto del proyecto se puede traer a ese
entorno
Puesta en Marcha de un Proyecto | 145
Seleccionar el enfoque del Preparar
proyecto y preparar el Expediente del Proyecto
Expediente del Proyecto
Crear
Enfoque del proyecto
Crear Descripciones de roles
adicionales
Actualizar
Archivo Diario
Considerar cualquier restricción de
●●
seguridad que sea aplicable al proyecto o al
funcionamiento de sus productos
●● Considerar cualquier necesidad de
capacitación del personal del usuario
■■ Preparar el Expediente del Proyecto:
●● Definir el proyecto:
●● Confirmar el estado actual del proyecto (por
ej., los antecedentes del proyecto y cualquier
trabajo de preparación realizado hasta la
fecha)
●● Confirmar los objetivos y los resultados
finales deseados
●● Confirmar el alcance del proyecto y las
exclusiones
●● Identificar cualquier restricción y suposición
●● Identificar las tolerancias del proyecto
●● Identificar al usuario, o usuarios, y cualquier
otra parte interesada conocida
●● Identificar las interacciones que el proyecto
debe mantener
●● Incorporar el Business Case preliminar
●● Incorporar la Descripción del Producto del
Proyecto
146 | Puesta en Marcha de un Proyecto

Tabla 12.5 Responsabilidades para seleccionar el enfoque del proyecto y preparar el Expediente del Proyecto

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción

Enfoque del proyecto Crear/seleccionar (A) (R) (R) P R

Descripciones de roles adicionales Crear (A) (R) (R) P R

Expediente del Proyecto Preparar (A) (R) (R) P R A.11

Archivo Diario Actualizar P A.2

Incorporar el enfoque del proyecto

●●
●● Revisar la estructura del equipo de gestión
del proyecto y las descripciones de los roles a
fin de identificar cualquier rol o competencia
adicional que se requieran para realizar
el trabajo. Preparar descripciones de roles
adicionales según sea necesario
●● Incorporar la estructura del equipo de
gestión del proyecto y las descripciones de
roles
■■ Utilizar el Archivo Diario para dejar constancia
de cualquier cuestión o riesgo nuevos.
La Tabla 12.5 muestra las responsabilidades para
esta actividad.
12.4.6 Planificar la fase de inicio
Iniciar un Proyecto lleva tiempo y consume
recursos. El trabajo se deberá planificar y deberá
ser aprobado, al igual que cualquier otro trabajo
en un proyecto. Esto también asegura que el inicio
no tenga lugar sin un propósito fijo y sin una
estructura.
Si el proyecto es parte de un programa, la fecha
final para la fase de inicio se deberá comprobar
con aquélla en los planes del programa. El
Plan de la Fase de Inicio también advertirá al
equipo de gestión del programa sobre cualquier
requerimiento del programa.

Expediente Planificar la Crear

del Proyecto Plan de la Fase
fase de Inicio

Actualizar
Archivo Diario Archivo Diario

Solicitud de Inicio
Archivo sobre las de un proyecto
Lecciones

Figura 12.7 Resumen de actividades para planificar la fase de inicio

 Puesta en Marcha de un Proyecto | 147

La aplicación de los procesos de PRINCE2 durante ●● Definir lo convenido en materia de

el Inicio de un Proyecto necesita ser considerada
como una parte del proceso de la Puesta en Marcha
de un Proyecto. Por ejemplo, el proyecto podría
elegir aplicar los procesos del Control de una Fase y
de la Gestión de la Entrega de Productos durante el
proceso del Inicio de un Proyecto.
La figura 12.7 muestra los aportes y resultados
relativos a esta actividad. Para más información
sobre planificación, véase el Capítulo 7.
PRINCE2 recomienda las siguientes acciones:
■■ En base al enfoque del proyecto, decidir los
controles de gestión adecuados para el proyecto
y suficientes para que pueda ser iniciado:
●● Revisar el Archivo sobre las Lecciones para
encontrar las lecciones relacionadas con los
controles del proyecto
dependencias y de controles para la fase de
inicio
■■ Identificar cualquier restricción en cuanto a
tiempo y costes para la fase de inicio y producir
el Plan de la Fase, de conformidad con los
principios y las técnicas del Capítulo 7
■■ Revisar cualquier riesgo en el Archivo Diario
y evaluar su impacto en el Plan de la Fase de
Inicio
■■ Si se identifica cualquier riesgo nuevo (o si los
existentes han cambiado), actualizar el Archivo
Diario
■■ Solicitar autorización para iniciar el proyecto.
La Tabla 12.6 muestra las responsabilidades para
esta actividad.

Tabla 12.6 Responsabilidades para planificar la fase de inicio

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Usuario Principal

Project Manager

Team Manager
Ejecutivo

Producto Acción
Plan de la Fase Crear (A) (A) (A) P R A.22

Archivo Diario Actualizar P A.2

 13
Dirección de
un Proyecto
13 Dirección de un Proyecto

13.1 Propósito 13.3 Contexto

El propósito del proceso de la Dirección de un El proceso de la Dirección de un Proyecto comienza
Proyecto es permitir a la Junta de Proyecto ser al terminar el proceso de la Puesta en Marcha de
responsable del éxito del proyecto al tomar un Proyecto y es activado por la solicitud de inicio
decisiones clave y ejercer control general, al mismo de un proyecto.
tiempo que delega la gestión diaria del proyecto al
El proceso de la Dirección de un Proyecto no cubre
Project Manager.
las actividades diarias del Project Manager, sino
las actividades de aquellos al nivel de gestión por
13.2 Objetivo encima del Project Manager: es decir, la Junta
de Proyecto. La Junta de Proyecto gestiona por
El objetivo del proceso de la Dirección de un
excepciones. Hace el seguimiento mediante
Proyecto es asegurar que:
informes y controla a través de una pequeña
■■ Haya autoridad para iniciar el proyecto cantidad de puntos de decisión. No deberían
■■ Haya autoridad para entregar los productos del necesitarse otras “reuniones de progreso” para la
proyecto Junta de Proyecto. El Project Manager informará
■■ Se proporcione control y dirección de gestión a la junta sobre cualquier situación de excepción.
durante toda la vida del proyecto y que el También es importante que los niveles de
proyecto se mantenga viable autoridad y los procesos de la toma de decisiones
■■ La gestión corporativa o del programa tenga estén claramente identificados.
interacción con el proyecto Es necesario que haya comunicación recíproca de
■■ Haya autoridad para cerrar el proyecto información entre la Junta de Proyecto y la gestión
■■ Se gestionen y revisen los planes para concretar corporativa o del programa durante el proyecto.
los beneficios post-proyecto. Crear enlaces con la gestión corporativa o del

Notificación Notificación de Solicitud de Asesoramiento Notificación

de inicio autorización del asesoramiento de y decisiones de cierre
proyecto la J. de Proyecto corporativas

Autorizar
el inicio
Autorizar Dirección de un Proyecto
el proyecto

Autorizar un Plan de la Fase

o de Excepción

Proporcionar dirección ad hoc

Autorizar el cierre
del proyecto

Solicitud de Solicitud de
Autorización aprobación del
de fase asesoramiento del Cuestión nueva
Plan de Excepción Project Manager
Solicitud de Asesoramiento y
Solicitud de inicio Autoridad para Solicitud de entrega Plan de Excepción aprobación del Plan Solicitud de Excepción Cierre Recomendación
de un proyecto iniciar un proyecto de un proyecto aprobado Plan de Excepción planteada decisiones de prematuro de cierre
de la Fase siguiente la J. de Proyecto

Puesta en Marcha Inicio de Gestión de Cierre de

de un Proyecto un Proyecto Límites de Fase un Proyecto

Control de una Fase

Figura 13.1 Visión general de la Dirección de un Proyecto

152 | Dirección de un Proyecto
programa y actuar como un canal de comunicación
es un rol principal de la Junta de Proyecto. Esta
necesidad, y la manera en que será satisfecha,
deberán documentarse en la Estrategia de Gestión
de la Comunicación.
La Junta de Proyecto debería ofrecer dirección
y orientación unificadas al Project Manager.
Si no es capaz de ofrecer una visión única o si
cada miembro de la Junta de Proyecto ofrece
asesoramiento independiente, y posiblemente
contradictorio, aumenta considerablemente el
riesgo de que el proyecto fracase. En tales casos, el
Project Manager debería guiarse por el liderazgo
del Ejecutivo.
La Junta de Proyecto es responsable de asegurar
que haya una justificación comercial continua. El
proceso de la Dirección de un Proyecto proporciona
un mecanismo para que la Junta de Proyecto logre
dicha garantía sin verse abrumada por la actividad
del proyecto.
Una de las funciones de la Junta de Proyecto
es proporcionar asesoramiento y orientación
informales, así como dirección formal, al Project
Manager. El Project Manager debería solicitar
asesoramiento en cualquier momento que sea
necesario durante la vida del proyecto.
13.4 Actividades
Las actividades dentro del proceso de la Dirección
de un Proyecto están orientadas a la Junta de
Proyecto e incluyen:
■■ Autorizar el inicio
■■ Autorizar el Proyecto
Solicitud de inicio
Autorizar el inicio
de un proyecto
Expediente
del Proyecto
Plan de la Fase
(Inicio)
Figura 13.2 Resumen de actividades para autorizar el inicio
■■ Autorizar un Plan de la Fase o de Excepción
■■ Proporcionar dirección ad hoc
■■ Autorizar el cierre del proyecto.
13.4.1 Autorizar el inicio
Iniciar proyectos lleva tiempo y cuesta dinero y por
consiguiente las actividades de inicio se deberán
planificar, supervisar y controlar. La actividad de la
Junta de Proyecto para autorizar el inicio asegura
que esa inversión valga la pena.
Una vez que se recibe una solicitud de la Puesta en
Marcha de un Proyecto para iniciar un proyecto, la
Junta de Proyecto debe decidir si permite que el
proyecto proceda a la fase de inicio. Esto se puede
hacer durante una reunión formal de la Junta de
Proyecto. La Junta de Proyecto podrá, sin embargo,
tomar la decisión sin necesidad de una reunión
formal, siempre que todos los miembros estén
de acuerdo y el Ejecutivo dé al Project Manager
instrucciones documentadas para proceder con el
inicio.
La Junta de Proyecto podría nombrar a la Garantía
del Proyecto y delegarle algunas de las acciones de
revisión y evaluación (por ej., inspección del Plan
de la Fase para la fase de inicio para confirmar que
es viable).
En una relación comercial entre cliente y
proveedor, el Proveedor Principal podría no estar
nombrado en este momento y/o su aprobación del
Expediente del Proyecto y sus componentes podría
no ser necesaria a fin de autorizar el inicio.
La Figura 13.2 muestra los aportes y resultados
relativos a esta actividad.
Aprobar Expediente
del Proyecto
Aprobar Plan de la Fase
(Inicio)
Autoridad para
iniciar un proyecto
Notificación
de inicio
 Dirección de un Proyecto | 153

PRINCE2 recomienda las siguientes acciones: ■■ Informar a todas las partes interesadas y a
las sedes que el proyecto se está iniciando y
■■ Revisar y aprobar el Expediente del Proyecto:
solicitar cualquier apoyo logístico necesario
Confirmar la definición del proyecto
●●
(por ej., medios de comunicación, equipos y
(incluyendo los hitos principales)
cualquier apoyo al proyecto) suficiente para la
●● Confirmar el enfoque del proyecto
fase de inicio
●● Confirmar formalmente los nombramientos
■■ Autorizar al Project Manager a que proceda con
al equipo de gestión del proyecto y la fase de inicio.
confirmar que todos los miembros han
aceptado sus roles La Tabla 13.1 muestra las responsabilidades para
■■ Revisar y aprobar la Descripción del Producto esta actividad.
del Proyecto:
●● Confirmar las expectativas de calidad del
13.4.2 Autorizar el proyecto
cliente Esta actividad será activada por una solicitud
●● Confirmar los criterios de aceptación de autorización por parte del Project Manager
para entregar el proyecto y se deberá realizar en
■■ Verificar que el Business Case preliminar
paralelo con la actividad para autorizar un Plan de
demuestre un proyecto viable. En este
la Fase o de Excepción (véase la sección 13.4.3).
momento el Business Case preliminar podría
sólo contener suficiente información para El objetivo de la autorización del proyecto es
justificar razonablemente que el proyecto decidir si se procede con el resto del proyecto. La
vale la pena. El Business Case detallado se Junta de Proyecto debe confirmar que:
desarrollará durante la fase de inicio
■■ Existe un Business Case adecuado y apropiado y
■■ Revisar y aprobar el Plan de la Fase para la fase
que muestra un proyecto viable
de inicio:
■■ El Plan de Proyecto es adecuado para entregar
●● Comprender cualquier riesgo que afecte la
el Business Case
decisión de autorizar la fase de inicio
■■ Las estrategias y controles del proyecto apoyan
●● Obtener o asignar los recursos que el Plan de
la entrega del Plan de Proyecto
la Fase necesita para la fase de inicio
■■ Se han establecido y planificado los mecanismos
●● Asegurar que haya mecanismos adecuados
para medir y revisar los beneficios del proyecto.
de presentación de informes y control para
Si la Junta de Proyecto no autoriza el proyecto,
la fase de inicio y fijar tolerancias para la
será necesario activar el cierre prematuro (véase el
misma
Capítulo 18).

Tabla 13.1 Responsabilidades para autorizar el inicio

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción

Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Expediente del Proyecto Aprobar (R) A A A (P) R A.11

Plan de la Fase de Inicio Aprobar A A A (P) R A.22

154 | Dirección de un Proyecto
La Junta de Proyecto podría nombrar a la Garantía
del Proyecto y delegarle algunas de las acciones
de revisión y evaluación (por ej., inspeccionar la
Estrategia de Gestión de la Comunicación para
confirmar que todas las partes interesadas estén
cubiertas).
La Figura 13.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar y aprobar la Documentación de Inicio
del Proyecto:
●● Confirmar que la definición del proyecto
es exacta y completa y que el enfoque del
proyecto es factible
●● Confirmar que las lecciones de proyectos
similares anteriores han sido revisadas e
incorporadas
●● Confirmar que la Estrategia de Gestión de
la Calidad es suficiente para asegurar que
se cumplan las expectativas de calidad y
aprobar la misma
●● Confirmar que los procedimientos definidos
en la Estrategia de Gestión del Riesgo son
suficientes para mantener los riesgos bajo
control y aprobar la misma. Confirmar que
ha habido una revisión de los riesgos y
que las respuestas al riesgo, tanto para las
amenazas como para las oportunidades, son
apropiadas y han sido planificadas
●● Confirmar que la Estrategia de Gestión de
la Configuración controlará adecuadamente
Solicitud de entrega Autorizar el proyecto
de un proyecto
Archivo sobre las
Lecciones
Documentación de
Inicio del Proyecto
Plan de Revisión
de Beneficios
Figura 13.3 Resumen de actividades para autorizar el proyecto
el estado (versiones y variantes) de los
productos del proyecto y aprobar la misma
●● Asegurar que las necesidades de información
de las partes interesadas y el calendario de
comunicaciones, según lo definido en la
Estrategia de Gestión de la Comunicación,
sean adecuados y aprobar la misma
●● Confirmar que todos los miembros del
equipo de gestión del proyecto han
aceptado sus roles y entienden el nivel de
delegación, y los relativos límites, sobre
la autoridad que la Junta de Proyecto ha
delegado (por ejemplo, a una Autoridad de
Cambios)
●● Asegurar que los controles del proyecto sean
adecuados para la naturaleza del proyecto
●● Confirmar la validez y la factibilidad del
Plan de Proyecto (incluyendo cualquier hito
principal y estructura de fase propuesta) y
aprobar el mismo
●● Revisar y aprobar la o las Descripciones de
Productos
●● Revisar las tolerancias para el proyecto
proporcionadas por la gestión corporativa
o del programa para asegurar que sean
apropiadas y realistas
●● Obtener o asignar los recursos que el
proyecto necesita (éstos se entregarán al
Project Manager fase por fase)
Aprobar Documentación de
Inicio del Proyecto
Aprobar Plan de Revisión
de Beneficios
Notificación de
autorización
del proyecto
Cierre
prematuro

Confirmar las propuestas para adaptar
●●
el método de gestión corporativa (o
del programa) del proyecto y cualquier
adaptación de PRINCE2
●● Verificar que el Business Case demuestra un
proyecto viable y aprobar el mismo
■■ Revisar y aprobar el Plan de Revisión de
Beneficios. Confirmar que aborda todos los
beneficios esperados y satisface las necesidades
de la gestión corporativa o del programa
■■ Notificar a la gestión corporativa o del
programa y a cualquier otra parte interesada
que el proyecto ha sido autorizado
■■ Autorizar al Project Manager a que entregue
el proyecto o informar al Project Manager que
cierre el proyecto prematuramente si se decide
no proceder.
La Tabla 13.2 muestra las responsabilidades para
esta actividad.
Tabla 13.2 Responsabilidades para el proyecto
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Archivo sobre las Lecciones Revisar
Documentación de Inicio del Proyecto Aprobar
Plan de Revisión de Beneficios Aprobar
Dirección de un Proyecto | 155
13.4.3 Autorizar un Plan de la Fase o de
Excepción
Es importante que una fase comience solamente
cuando la Junta de Proyecto lo indique. La Junta
de Proyecto autoriza una fase de gestión al revisar
el desarrollo de la fase actual y al aprobar el Plan
de la Fase para la fase siguiente. La aprobación
de los Planes de Fase ocurre al final de cada fase
de gestión, salvo la última, cuando el proyecto se
cierra.
Si durante la fase ha ocurrido una excepción, la
Junta de Proyecto puede solicitar que el Project
Manager produzca un Plan de Excepción para
su aprobación por la Junta de Proyecto. Sólo
es necesario presentar para su aprobación las
excepciones a los Planes de Fase o a los Planes de
Proyecto. Las desviaciones del Plan de Proyecto
podrían requerir la aprobación de la gestión
corporativa o del programa. Por otro lado,
las excepciones a un Paquete de Trabajo son
gestionadas por el Project Manager mediante el
uso del proceso del Control de una Fase (véase el
Capítulo 15). Si se aprueba, el Plan de Excepción
reemplazará al plan que se encuentra en excepción
y pasará a ser la nueva versión baseline del plan.
La Junta de Proyecto podría nombrar a la Garantía
del Proyecto para delegarle algunas de las acciones
de revisión y evaluación (por ej., inspeccionar el
Plan de la Fase para confirmar que es viable).
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
R R R (P) R A.1
R A A A (P) R A.6
A A A A (P) R A.23
156 | Dirección de un Proyecto

(Si se ha actualizado)
Solicitud de Autorizar un Plan de una Fase Aprobar
aprobación del Documentación de
Plan de Excepción o de Excepción Inicio del Proyecto

Solicitud de
aprobación del Plan
de la Fase siguiente Aprobar Informe al Final de Fase
(fase en curso)

Informe al Final de la Fase

(fase en curso)
Aprobar Informe sobre las
Lecciones (si se requiere)

Informe sobre las

Lecciones (si se requiere)
Aprobar Acciones a realizar
recomendadas
(si se requieren)
Acciones a realizar
recomendadas
(si se requieren) Aprobar Plan de la Fase
(fase siguiente)

Plan de la Fase
(fase siguiente) (Si se ha actualizado)
Aprobar
Plan de Revisión
de Beneficios

Plan de Excepción Autorización

de fase

Plan de Revisión Cierre

de Beneficios prematuro

Autorización del
Documentación de Plan de Excepción
Inicio del Proyecto

Figura 13.4 Resumen de actividades para autorizar un Plan de la Fase o de Excepción

La Figura 13.4 muestra los aportes y resultados ●● Si se ha decidido entregar productos al

relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar y aprobar el Informe al Final de Fase:
●● Determinar el desarrollo del proyecto hasta
la fecha, solicitando al Project Manager que
explique cualquier desviación de los planes
aprobados y que facilite un pronóstico de
desarrollo del proyecto para el resto del
proyecto
●● Si se requiere, revisar el Informe sobre las
Lecciones y acordar quién debería recibirlo.
Asegurar que los grupos apropiados
(por ejemplo, la gestión corporativa o
del programa o un centro de excelencia)
conozcan su responsabilidad de llevar
adelante cualquier recomendación
●● Comprobar el resumen de riesgos para
asegurar que la exposición todavía sea
aceptable y que las respuestas al riesgo, tanto
para oportunidades como para amenazas,
sean apropiadas y se hayan planificado
cliente fase por fase:
●● Verificar que la entrega del producto
se haya hecho de conformidad con la
Estrategia de Gestión de la Configuración
y, en particular, que para cada producto
se cuente con aceptación por el usuario y
aceptación de uso y mantenimiento
●● Donde corresponda, asegurar que los
cambios resultantes en el negocio tengan
apoyo y sean sostenibles
●● Confirmar quién debería ser el
destinatario de cada recomendación
de acción a realizar, si las hay, según el
resumen en el Informe al Final de Fase
(en algunos casos podría ser necesario
revisar la recomendación detallada para
determinar algunas de las acciones a
realizar recomendadas). Asegurar que
los grupos apropiados (por ejemplo,
operaciones o mantenimiento) conozcan
su responsabilidad de llevar adelante
eventuales recomendaciones.
 Dirección de un Proyecto | 157

■■ Revisar el Plan de la Fase o el Plan de Excepción ■■ Tomar una decisión:

para el cual el Project Manager solicita
aprobación:
●● Confirmar la validez y la factibilidad del Plan
de la Fase/Plan de Excepción
●● Revisar y aprobar cualquier Descripción de
Producto nueva
●● Confirmar la validez y la factibilidad del
Plan de Proyecto. Si es necesario, obtener
las aprobaciones apropiadas de la gestión
corporativa o del programaConfirmar que
las estrategias y los controles del proyecto
en la Documentación de Inicio del Proyecto
(actualizada) son adecuados para el resto del
proyecto
●● Verificar que el Business Case (actualizado)
continúe mostrando un proyecto viable
●● Revisar y aprobar el Plan de Revisión de
Beneficios (actualizado) para asegurar que
se mida y se revise cualquier beneficio que
se ha planificado que se logrará en la fase
siguiente
●● Aprobar el o los planes y autorizar al Project
Manager a que proceda con el o los planes
presentados:
●● Obtener o asignar los recursos que el o
los planes requieren
●● Fijar tolerancias para el plan que se está
aprobando (para la fase final la Junta de
Proyecto debería considerar si cualquier
tolerancia residual de las fases anteriores
puede ser asignada al plan o si es mejor
mantenerlas en reserva)
●● O pedir al Project Manager que revise el
plan rechazado dando orientación sobre los
cambios requeridos para que sea aceptable
●● O dar instrucciones al Project Manager para
que inicie el cierre prematuro del proyecto
■■ Comunicar el estado del proyecto a la gestión
corporativa o del programa y mantener a otras
partes interesadas informadas sobre el progreso
del proyecto (de conformidad con la Estrategia
de Gestión de la Comunicación).
La Tabla 13.3 muestra las responsabilidades para
esta actividad.

Tabla 13.3 Responsabilidades para autorizar un Plan de la Fase o de Excepción

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Productos especializados Confirmar aprob. A A A (R) (P) (R)
Informe al Final de Fase Aprobar A A A (P) R A.13

Informe sobre las Lecciones Distribuir A R R (P) R A.20

Acciones a realizar recomendadas Distribuir A A A (P) R

Plan de la Fase siguiente Aprobar A A A (P) R A.22

Plan de Excepción Aprobar A A A (P) R A.22

Documentación de Inicio del Proyecto (Actualizada) Aprobar (R) A A A (P) R A.6

Plan de Revisión de Beneficios (Actualizado) Aprobar A A R R (P) R A.23

158 | Dirección de un Proyecto
13.4.4 Proporcionar dirección ad hoc
En cualquier momento durante un proyecto, los
miembros de la Junta de Proyecto podrán ofrecer
orientación informal o responder a solicitudes de
asesoramiento. Es probable que la necesidad de
consulta entre el Project Manager y la Junta de
Proyecto sea muy frecuente durante la fase de
inicio y al acercarse a los límites de una fase.
La dirección ad hoc podrá ser dada colectivamente
o por miembros individuales de la Junta de
Proyecto. Hay una serie de circunstancias que
podrían dar origen a dirección ad hoc, incluyendo:
■■ Responder a solicitudes (por ej., cuando
es necesario aclarar opciones o cuando es
necesario resolver áreas de conflicto)
■■ Responder a informes (por ej., al Informe de
Desarrollo, Informe de Excepción, Informe de
Cuestiones)
■■ Responder a influencias externas (por ej.,
cambios en prioridades corporativas)
■■ Preocupaciones individuales de los miembros de
la Junta de Proyecto
■■ Responder a cambios en la composición de
la Junta de Proyecto (que también podrían
requerir aprobación corporativa o del
programa).
Solicitud de Proporcionar
asesoramiento del
Project Manager dirección ad hoc
Excepción
planteada
Asesoramiento y
decisiones
corporativas
Informe de Desarrollo
Informe de Excepción
Informe de Cuestiones
Figura 13.5 Resumen de actividades para proporcionar dirección ad hoc
También es posible que la gestión corporativa o
del programa revise el mandato de proyecto en
respuesta a eventos externos al proyecto o instruya
a la Junta de Proyecto para que cierre el proyecto.
La Junta de Proyecto tiene dos opciones principales
si la gestión corporativa o del programa decide
cambiar el mandato de proyecto:
■■ Tratar esto como una solicitud de cambio (véase
el Capítulo 9) – pidiendo al Project Manager la
replanificación de la fase y/o del proyecto
■■ Detener y volver a iniciar el proyecto activando
el cierre prematuro (véase el Capítulo 18).
Esto podría dar lugar a costes adicionales en
comparación con la opción de una solicitud de
cambio.
La Junta de Proyecto podrá nombrar a la Garantía
del Proyecto para delegarle algunas de las
acciones de revisión y evaluación (por ejemplo,
inspección de una solicitud de cambio para
confirmar que se ha realizado una evaluación
adecuada del impacto). Al tomar decisiones es
importante considerar el impacto en todas las
partes interesadas (que han sido identificadas en la
Estrategia de Gestión de la Comunicación).
La figura 13.5 muestra los aportes y resultados
relativos a esta actividad.
Solicitud
de asesoramiento de
la Junta de Proyecto
Asesoramiento de
la Junta de Proyecto
Solicitud de
Plan de Excepción
Cierre
prematuro
Plantear Cuestión
nueva
 Dirección de un Proyecto | 159

PRINCE2 recomienda las siguientes acciones: ●● Tomar una decisión dentro de los límites de
autoridad delegada de la Junta de Proyecto
■■ En respuesta a solicitudes de asesoramiento y
para:
orientación informales:
●● Incrementar las tolerancias que se prevé
●● Solicitar asesoramiento de la gestión
se incumplirán
corporativa o del programa si es necesario
●● Dar instrucciones al Project Manager
●● Asistir al Project Manager según se requiera
para que produzca un Plan de Excepción
(esto podría incluir pedir al Project Manager
(indicando aquello que será aceptable)
que produzca un Informe de Cuestiones y/o
●● Dar instrucciones al Project Manager para
un Informe de Excepción)
que cierre el proyecto prematuramente
■■ En respuesta a un Informe de Cuestiones (véase
●● Diferir la excepción durante un período
el Capítulo 9):
de tiempo fijo. Ésta es una respuesta
●● Solicitar asesoramiento de la gestión
útil si hay poca confianza en la previsión
corporativa o del programa si es necesario
(que se excederán las tolerancias) o si
●● Tomar una decisión dentro de los límites de
la excepción depende de que ocurra un
autoridad delegada de la Junta de Proyecto.
riesgo
Esta decisión podría relacionarse con:
■■ En respuesta a la recepción de un Informe de
●● Un problema/asunto Solicitar un Plan de
Desarrollo (véase el Capítulo 10):
Excepción o proporcionar orientación
●● Revisar el Informe de Desarrollo para
●● Una solicitud de cambio Aprobar, diferir,
comprender el estado del proyecto
rechazar o solicitar más información.
●● Asegurar que el proyecto continúe centrado
Considerar si se requiere un Plan de
en los objetivos corporativos o del programa
Excepción
fijados y continúe estando justificado de
●● Fuera de especificación Otorgar una
conformidad con su Business Case
concesión, diferir, rechazar o solicitar más
●● Asegurar que la fase esté progresando según
información. Considerar si se requiere un
el plan
Informe de Excepción
●● Mantener a la gestión corporativa o del
■■ En respuesta a un Informe de Excepción (véase
programa y a otras partes interesadas
el Capítulo 10):
informadas acerca del progreso del proyecto,
●● Solicitar asesoramiento de la gestión
según lo definido por la Estrategia de
corporativa o del programa si es necesario
Gestión de la Comunicación

Tabla 13.4 Responsabilidades para proporcionar dirección ad hoc

Productor – responsable de la producción del producto Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Usuario Principal

Project Manager

Team Manager
Ejecutivo

Producto Acción
Informe de Desarrollo Inspeccionar R R R (P) R A.16

Informe de Excepción Responder R R R (P) R A.17

Cuestión nueva Plantear P P P P

160 | Dirección de un Proyecto
Tomar medidas según sea necesario. Por
●●
ejemplo, pedir al Project Manager que
produzca un Informe de Cuestiones y/o un
Informe de Excepción
■■ En respuesta a asesoramiento y decisiones de la
gestión corporativa o del programa:
●● Asegurar que se mantenga informado
al equipo de gestión del proyecto sobre
eventos externos que podrían afectarle (por
ejemplo, informar al Project Manager sobre
un cambio en el personal de la Junta de
Proyecto)
●● Notificar al Project Manager cualquier
cambio en el entorno corporativo o del
programa que pueda tener un impacto en el
proyecto y asegurar que se tomen medidas
apropiadas. Esto podría incluir:
●● Plantear una cuestión al Project Manager
●● Dar instrucciones al Project Manager para
que produzca un Plan de Excepción
●● Dar instrucciones al Project Manager para
que cierre prematuramente el proyecto.
La Tabla 13.4 muestra las responsabilidades para
esta actividad.
Autorizar el
Recomendación
cierre del proyecto
de cierre
Documentación de
Inicio del Proyecto
Business Case
(Actualizado)
Informe al
Final de Proyecto
Informe sobre
las Lecciones
Acciones a realizar
recomendadas
Plan de Revisión
de Beneficios
Figura 13.6 Resumen de actividades para autorizar el cierre del proyecto
13.4.5 Autorizar el cierre del proyecto
El cierre controlado de un proyecto es tan
importante como el inicio controlado. Debe
haber un punto en el cual se evalúan los objetivos
expuestos en la versión original y la versión actual
de la Documentación de Inicio del Proyecto y del
Plan de Proyecto a fin de comprender:
■■ Si se han logrado los objetivos
■■ La manera en que el proyecto se ha desviado de
su base inicial
■■ Que el proyecto no tiene nada más para
aportar.
Sin este enfoque, el proyecto podría no terminar
nunca; un proyecto puede pasar a ser negocio
habitual, cosa que resultaría en la pérdida del
enfoque original en los beneficios.
Autorizar el cierre del proyecto es la última
actividad realizada por la Junta de Proyecto
con anterioridad a su propia disolución y podría
requerir la aprobación de la gestión corporativa o
del programa.
La Junta de Proyecto podrá nombrar a la Garantía
del Proyecto para delegarle algunas de las acciones
de revisión y evaluación (por ej., inspección del
Informe al Final de Proyecto para confirmar que es
exacto).
Aprobar Informe al
Final de Proyecto
Informe sobre
las Lecciones
Acciones a realizar
recomendadas
Aprobar Business Case
(Actualizado)
Aprobar (Si se ha actualizado)
Plan de Revisión
de Beneficios
Notificación
de cierre
 Dirección de un Proyecto | 161

La Figura 13.6 muestra los aportes y resultados necesario transferir la responsabilidad de este
relativos a esta actividad. plan a la gestión corporativa o del programa
■■ Confirmar el Business Case actualizado
PRINCE2 recomienda las siguientes acciones:
comparando los beneficios, costes y riesgos
■■ Revisar la versión original y la versión actual reales y previstos con el Business Case original
de la Documentación de Inicio del Proyecto que se utilizó para justificar el proyecto (quizás
para comprender la versión baseline inicial del no sea posible confirmar todos los beneficios ya
proyecto y las estrategias y controles actuales que algunos no se concretarán hasta después
■■ Revisar y aprobar el Informe al Final de del cierre del proyecto)
Proyecto para: ■■ Revisar y expedir una notificación de cierre
●● Comprender el rendimiento real del proyecto del proyecto de conformidad con la Estrategia
en función de su base inicial, incluyendo de Gestión de la Comunicación. La Junta de
un resumen de cualquier desviación de los Proyecto informa a quienes han provisto la
planes aprobados infraestructura de soporte y recursos para el
●● Confirmar quién debería recibir cada acción proyecto que éstos se pueden retirar ahora. Se
a realizar recomendada según lo resumido debería indicar una fecha límite para cargar
en el Informe al Final de Proyecto (en costes al proyecto.
algunos casos podría ser necesario revisar la La Tabla 13.5 muestra las responsabilidades para
recomendación detallada para algunas de las esta actividad.
acciones a realizar). Asegurar que los grupos
apropiados (por ejemplo, operaciones o
mantenimiento) conozcan su responsabilidad
de llevar adelante cualquier acción
recomendada
●● Revisar el Informe sobre las Lecciones y
convenir quién debería recibirlo. Asegurar
que los grupos apropiados (por ejemplo,
la gestión corporativa o del programa
o un centro de excelencia) conozcan
su responsabilidad de llevar adelante
eventuales recomendaciones
●● Verificar que la entrega de los productos del
proyecto se haya hecho de conformidad con
la Estrategia de Gestión de la Configuración
y, en particular, que para cada producto
se cuente con aceptación por el usuario
y aceptación de uso y mantenimiento.
Asegurar que, en los casos en que sea
apropiado, los cambios resultantes en el
negocio tengan apoyo y sean sostenibles
■■ Asegurar que la revisión de los beneficios post-
proyecto cubra el desarrollo de los productos
del proyecto durante su uso operacional a
fin de identificar si ha ocurrido cualquier
consecuencia indirecta (beneficiosa o adversa)
■■ Revisar y obtener aprobación para el Plan de
Revisión de Beneficios actualizado, asegurando
que aborde los beneficios esperados que
todavía no se pueden confirmar. Debido a
que el Plan de Revisión de Beneficios incluye
recursos más allá de la vida del proyecto, es
162 | Dirección de un Proyecto

Tabla 13.5 Responsabilidades para autorizar el cierre del proyecto

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Informe al Final de Proyecto Aprobar A A A (P) R A.14

Informe sobre las Lecciones Distribuir A A A (P) R A.20

Acciones a realizar recomendadas Distribuir A A A (P) R

Business Case (Actualizado) Confirmar R A R R (P) R A.3

Plan de Revisión de Beneficios (Actualizado) Aprobar A A R R (P) R A.23

 14
Inicio de un Proyecto
14 Inicio de un Proyecto

14.1 Propósito ■■ Las razones para realizar el proyecto, los

beneficios esperados y los riesgos asociados
El propósito del proceso del Inicio de un Proyecto
■■ El alcance de lo que se debe hacer y los
es establecer bases sólidas para el proyecto,
productos a entregar
permitiendo a la organización comprender el
trabajo que se debe realizar para entregar los ■■ Cómo y cuándo se entregarán los productos del
productos del proyecto antes de comprometerse a proyecto y a qué coste
un gasto considerable. ■■ Quién participará en la toma de decisiones del
proyecto
■■ Cómo se alcanzará la calidad requerida
14.2 Objetivo
■■ Cómo se establecerán y controlarán las
El objetivo del proceso del Inicio de un Proyecto es versiones baseline
asegurar que haya comprensión común sobre: ■■ Cómo se identificarán, evaluarán y controlarán
los riesgos, las cuestiones y los cambios

Dirección de un Proyecto

Autoridad para
iniciar un proyecto

Preparar la Preparar la Preparar la

Estrategia de Estrategia de Estrategia de Gestión
Gestión del Riesgo Gestión de la Calidad de la Configuración

Preparar la
Estrategia de Gestión
de la Comunicación

Establecer los Crear el

controles del proyecto Plan de Proyecto

Perfeccionar el
Business Case

Preparar la
Documentación de Solicitud de
entrega de
Inicio del Proyecto
Inicio de un Proyecto un proyecto

Se acerca el Gestión de los

límite de fase Límites de Fase

Figura 14.1 Visión general del Inicio de un Proyecto

166 | Inicio de un Proyecto
■■ Cómo se supervisará y controlará el progreso
■■ Quién necesita información, en qué formato y
en qué momento
■■ Cómo se adaptará el método de gestión
corporativa (o del programa) del proyecto para
adecuarse a éste.
14.3 Contexto
El Inicio de un Proyecto busca establecer las
bases a fin de lograr que el proyecto tenga éxito.
Específicamente, todas las partes deben tener
claridad sobre aquello que el proyecto busca
lograr, por qué se necesita, cómo se ha de lograr el
resultado final y cuáles son sus responsabilidades,
de modo que pueda haber un verdadero
compromiso hacia el mismo.
El proceso del Inicio de un Proyecto permite a la
Junta de Proyecto decidir, a través de la Dirección
de un Proyecto (véase el Capítulo 13), si el proyecto
está o no lo suficientemente alineado con los
objetivos corporativos o del programa para
autorizar su continuación.
Si, en cambio, la organización procediera
directamente desde la Puesta en Marcha de un
Proyecto (véase el Capítulo 12) hasta el Control
de una Fase (véase el Capítulo 15), podría verse
forzada a asignar recursos financieros considerables
a un proyecto, sin comprender totalmente la
manera en que se lograrán sus objetivos. Sin una
definición firme, la Junta de Proyecto estaría
haciendo un salto al vacío.
Si la relación entre el cliente y el proveedor es
una relación comercial, (por ejemplo, las razones
para realizar el proyecto según lo definido en el
Business Case del proveedor podrían ser diferentes
de aquellos que se han definido en el Business
Case del cliente), será necesario considerar más aún
todas las actividades dentro del proceso del Inicio
de un Proyecto – véase el Capítulo 19 para más
información.
Durante el proceso del Inicio de un Proyecto, el
Project Manager creará el conjunto de productos
de gestión requeridos para el nivel de control
especificado por la Junta de Proyecto. El Project
Manager debería haber convenido (como parte
del Plan de la Fase de inicio) los medios con los
cuales la Junta de Proyecto revisará y aprobará los
productos de gestión – los dos extremos son uno
por vez o todos a la vez.
14.4 Actividades
Las actividades dentro del proceso del Inicio de un
Proyecto están orientadas al Project Manager e
incluyen:
■■ Preparar la Estrategia de Gestión del Riesgo
■■ Preparar la Estrategia de Gestión de la
Configuración
■■ Preparar la Estrategia de Gestión de la Calidad
■■ Preparar la Estrategia de Gestión de la
Comunicación
■■ Establecer los controles del proyecto
■■ Crear el Plan de Proyecto
■■ Perfeccionar el Business Case
■■ Preparar la Documentación de Inicio del
Proyecto.
Las actividades para establecer las estrategias para
el proyecto se podrán ejecutar en paralelo, pero
se recomienda que la Estrategia de Gestión de la
Comunicación sea la última en completarse ya que
necesitará incluir cualquier comunicación requerida
de las otras estrategias.
Las estrategias se derivan de las estrategias de
gestión corporativa o del programa, de las normas
o prácticas que el proyecto necesita cumplir y de
las expectativas de calidad del cliente registradas
en la Descripción del Producto del Proyecto. Una
vez definidas las estrategias, es posible establecer
los controles para el proyecto y crear el Plan de
Proyecto. Éstas son actividades paralelas e iterativas
ya que:
■■ Cada control necesitará tiempo y recursos para
operar, los cuales deberán ser documentados en
el Plan de Proyecto
■■ Se podrían requerir controles adicionales
a medida que se identifican productos y
actividades en el Plan de Proyecto.
Una vez que los controles han sido establecidos
y que se ha creado un Plan de Proyecto, será
posible completar el Business Case ya que ahora
se comprenderán totalmente las previsiones de
tiempo y costes de desarrollo de los productos del
proyecto y de gestión del proyecto.
La actividad final en el proceso del Inicio de un
Proyecto es preparar la Documentación de Inicio
del Proyecto. Ésta es una compilación de toda la
documentación desarrollada durante el inicio del
proyecto que se utilizará para lograr la aprobación
de la Junta de Proyecto para proceder.

14.4.1 Preparar la Estrategia de Gestión
del Riesgo
La Estrategia de Gestión del Riesgo describe las
finalidades de la aplicación de la gestión del
riesgo, el procedimiento que se adoptará, los roles
y responsabilidades, la tolerancia de riesgos, la
secuencia temporal de las actividades de gestión
del riesgo, las herramientas y técnicas que se
utilizarán y las exigencias de presentación de
informes.
Para más información sobre la gestión del riesgo,
véase el Capítulo 8.
La Figura 14.2 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto para
comprender si el proyecto necesita aplicar
cualquier estrategia de gestión corporativa o
del programa, norma o práctica relacionadas
con la gestión del riesgo
■■ Buscar lecciones relacionadas con la gestión
del riesgo de proyectos similares anteriores,
de la gestión corporativa o del programa y
de organizaciones externas. Algunas de éstas
podrían haber sido ya registradas en el Archivo
sobre las Lecciones
■■ Revisar el Archivo Diario para encontrar
cualquier cuestión y riesgo relacionado con la
gestión del riesgo
■■ Definir la Estrategia de Gestión del Riesgo,
incluyendo:
Figura 14.2 Resumen de actividades para preparar la Estrategia de Gestión del Riesgo
Preparar la
Autoridad para Estrategia de
iniciar un proyecto
Gestión del Riesgo
Expediente
del Proyecto
Archivo sobre las
Lecciones
Archivo Diario
Inicio de un Proyecto | 167
●● El procedimiento de gestión del riesgo
(por ej., Identificar, Evaluar, Planificar,
Implementar, Comunicar)
●● Las herramientas y técnicas que se utilizarán
●● Los testimonios documentales que se
guardarán
●● La manera en que se informará sobre el
rendimiento de la gestión del riesgo
●● La secuencia temporal de las actividades de
gestión del riesgo
●● Los roles y responsabilidades para las
actividades de gestión del riesgo
●● Las escalas a ser utilizadas para calcular la
probabilidad y el impacto
●● Orientación sobre la manera en que se
evaluará la proximidad para los riesgos
●● Definición de las categorías de riesgo a ser
utilizadas
●● Cualquier sistema de alerta anticipada a ser
utilizado
●● Las tolerancias relacionadas con el riesgo
●● Si se establecerá un presupuesto para
riesgos y, de ser así, la manera en que será
controlado
■■ Consultar a la Garantía del Proyecto para
comprobar que la Estrategia de Gestión del
Riesgo propuesta satisfaga las necesidades de la
Junta de Proyecto y/o de la gestión corporativa
o del programa
■■ Crear el Registro de Riesgos de conformidad
con la Estrategia de Gestión del Riesgo y
cumplimentar el mismo con cualquier riesgo del
Archivo Diario
(Parte de la)
Documentación de
Inicio del Proyecto
Crear Estrategia de
Gestión del Riesgo
Crear Registro de Riesgos
168 | Inicio de un Proyecto
■■ Solicitar de la Junta de Proyecto la aprobación
de la Estrategia de Gestión del Riesgo (aunque
la Junta de Proyecto podría preferir revisar
la misma más adelante como parte de la
Documentación de Inicio del Proyecto).
La Tabla 14.1 muestra las responsabilidades para
esta actividad.
14.4.2 Preparar la Estrategia de Gestión
de la Configuración
La gestión de la configuración es esencial para que
el proyecto mantenga control de su gestión y de
sus productos especializados.
El nivel de control requerido variará de un proyecto
a otro. El mayor nivel de control posible se
determina al desglosar los productos del proyecto
hasta alcanzar el nivel en el cual un componente
se puede instalar, reemplazar o modificar
independientemente. Sin embargo, el nivel de
control ejercido dependerá de la importancia del
proyecto y de la complejidad de la relación entre
sus productos.
El conjunto inicial de Fichas de Elementos de
Configuración se creará durante esta actividad. La
Estrategia de Gestión de la Configuración definirá
el formato y la composición de las fichas que es
necesario mantener (véase el Apéndice A).
Para más información sobre la gestión de la
configuración, véase el Capítulo 9.
Tabla 14.1 Responsabilidades para preparar la Estrategia de Gestión del Riesgo
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Estrategia de Gestión del Riesgo Crear
Registro de Riesgos Crear y cumplimentar
La Figura 14.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto a fin de
comprender si se debe aplicar cualquier
estrategia de gestión corporativa o del
programa, norma o práctica relacionadas con
la gestión de la configuración (en particular si
el cliente y/o el proveedor tienen un sistema
de gestión de la configuración existente que se
debería aplicar)
■■ Buscar lecciones de proyectos similares
anteriores, de la gestión corporativa o del
programa y de organizaciones externas
relacionadas con la gestión de la configuración.
Algunas de éstas podrían haber sido ya
registradas en el Archivo sobre las Lecciones
■■ Revisar el Registro de Riesgos y el Archivo
Diario para encontrar los riesgos y las cuestiones
asociados con la gestión de la configuración
■■ Definir la Estrategia de Gestión de la
Configuración, incluyendo:
●● El procedimiento de gestión de la
configuración (por ej., planificación,
identificación, control, informes sobre
estados, verificación y auditoría)
●● El procedimiento para la gestión de las
cuestiones y control de cambios (por ej.,
registrar, examinar, proponer, decidir,
implementar)
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R A.10
A R P A.26
 Inicio de un Proyecto | 169

Preparar la (Parte de la)

Autoridad para Estrategia de Documentación de
iniciar un proyecto Inicio del Proyecto
Gestión de la Configuración

Expediente Crear Estrategia de

del Proyecto Gestión de la
Configuración

Actualizar Estructura del equipo

Archivo sobre las
de gestión del proyecto
Lecciones

Actualizar Descripciones
de roles
Registro de Riesgos

Crear Fichas de Elementos

de Configuración
Archivo Diario

Crear
Registro de Cuestiones

Figura 14.3 Resumen de actividades para preparar la Estrategia de Gestión de la Configuración

●● Las herramientas y técnicas que se utilizarán
●● Los testimonios documentales que se
guardarán
●● La manera en que se informará sobre el
rendimiento de los procedimientos
●● La secuencia temporal de las actividades de
gestión de la configuración y las actividades
de gestión de las cuestiones y de control de
cambios
●● Los roles y responsabilidades para los
procedimientos. Considerar si se debe
establecer una Autoridad de Cambios y/o un
presupuesto para cambios
●● Las escalas para prioridad y severidad de las
cuestiones
■■ Consultar a la Garantía del Proyecto para
comprobar que la Estrategia de Gestión de
la Configuración propuesta satisfaga las
necesidades de la Junta de Proyecto y/o de la
gestión corporativa o del programa
■■ Crear las Fichas iniciales de los Elementos de
Configuración (en este momento sólo habrá
Fichas para los productos de gestión que ya
han sido creados y cualquier documentación
preexistente del proyecto que necesita ser
controlada, por ej., estudio de viabilidad,
solicitud de propuesta, etc.)
■■ Crear el Registro de Cuestiones y considerar si
cualquier cuestión ya registrada en el Archivo
Diario necesita gestionarse formalmente y por
consiguiente transferirse
■■ Si se identifica cualquier riesgo o cuestión
nuevos (o si los existentes han cambiado),
actualizar el Registro de Riesgos, el Registro de
Cuestiones y/o el Archivo Diario
■■ Solicitar de la Junta de Proyecto la aprobación
de la Estrategia de Gestión de la Configuración
(la Junta de Proyecto podría preferir revisar
la misma más adelante como parte de la
Documentación de Inicio del Proyecto).
La Tabla 14.2 muestra las responsabilidades para
esta actividad.
14.4.3 Preparar la Estrategia de Gestión
de la Calidad
Un factor principal para el éxito de cualquier
proyecto es que entregue aquello que el usuario
espera y considera aceptable. Esto sólo sucederá
si estas expectativas se estipulan y se acuerdan al
comenzar el proyecto, junto con las normas a ser
utilizadas y los medios para evaluar su logro. El
propósito de la Estrategia de Gestión de la Calidad
es asegurar que dichos acuerdos se registren y
mantengan.
Para más información sobre gestión de calidad,
véase el Capítulo 6.
170 | Inicio de un Proyecto

Tabla 14.2 Responsabilidades para preparar la Estrategia de Gestión de la Configuración

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Estrategia de Gestión de la Configuración Crear (A) (A) (A) P R A.9

Fichas de Elementos de Configuración (iniciales) Crear A R P A.12

Registro de Cuestiones Crear y cumplimentar A R P A.25

La Figura 14.4 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar la Descripción del Producto del
Proyecto para comprender las expectativas de
calidad del cliente y para comprobar que los
criterios de aceptación del proyecto estén lo
suficientemente definidos
■■ Revisar el Expediente del Proyecto para
comprender si el proyecto necesita aplicar
cualquier estrategia de gestión corporativa o
Autoridad para
iniciar un proyecto
Gestión de la Calidad
del programa, norma o práctica relacionadas
con la gestión de la calidad (en particular si el
cliente y/o el proveedor tienen un sistema de
gestión de la calidad existente que se debería
aplicar a aspectos del proyecto)
■■ Buscar lecciones de proyectos similares
anteriores, de la gestión corporativa o del
programa y de organizaciones externas
relacionadas con la gestión de la calidad.
Algunas de éstas podrían haber sido ya
registradas en el Archivo sobre las Lecciones
Preparar la (Parte de la)
Estrategia de Documentación de
Inicio del Proyecto

Expediente Crear Estrategia de

del Proyecto Gestión de la Calidad

Crear Registro de Calidad

Descripción del
Producto del Proyecto

Archivo sobre
las Lecciones

Registro de Riesgos

Registro de Cuestiones

Figura 14.4 Resumen de actividades para preparar la Estrategia de Gestión de la Calidad


■■ Revisar el Registro de Riesgos y el Registro
de Cuestiones para encontrar los riesgos y las
cuestiones asociados con la gestión de la calidad
■■ Definir la Estrategia de Gestión de la Calidad,
incluyendo:
●● El procedimiento de gestión de la calidad
(por ej., planificación de la calidad, control
de calidad, garantía de calidad)
●● Las herramientas y técnicas que se utilizarán
●● Los testimonios documentales que se
guardarán
●● La manera en que se informará sobre el
rendimiento del procedimiento de la gestión
de la calidad
●● La secuencia temporal de las actividades de
gestión de la calidad
●● Los roles y responsabilidades para las
actividades de gestión de la calidad
(comprobar los enlaces a cualquier función
de garantía de calidad corporativa o
del programa y asegurar que todas las
actividades del proyecto relacionadas con la
calidad apoyen y estén apoyadas por esta
función)
■■ Consultar a la Garantía del Proyecto para
comprobar que la Estrategia de Gestión de la
Calidad propuesta satisfaga las necesidades
de la Junta de Proyecto y/o de la gestión
corporativa o del programa
■■ Crear un Registro de Calidad para dejar
constancia de los detalles de todas las
Tabla 14.3 Responsabilidades para preparar la Estrategia de Gestión de la Calidad
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Estrategia de Gestión de la Calidad Crear
Registro de Calidad Crear
Inicio de un Proyecto | 171
actividades relacionadas con la calidad que de
desarrollen a lo largo del proyecto
■■ Si se identifica cualquier riesgo o cuestión
nuevos (o si los existentes han cambiado),
actualizar el Registro de Riesgos, el Registro de
Cuestiones y/o el Archivo Diario
■■ Solicitar de la Junta de Proyecto la aprobación
de la Estrategia de Gestión de la Calidad
(aunque la Junta de Proyecto podría preferir
revisar la misma más adelante como parte de la
Documentación de Inicio del Proyecto).
La Tabla 14.3 muestra las responsabilidades para
esta actividad.
14.4.4 Preparar la Estrategia de Gestión
de la Comunicación
La Estrategia de Gestión de la Comunicación
aborda las comunicaciones tanto internas como
externas. Debería contener detalles de la manera
en que el equipo de gestión del proyecto enviará
y recibirá información de la o las organizaciones
directa e indirectamente relacionadas con el
proyecto o que se ven afectadas por el mismo. En
particular, en los casos en que el proyecto es parte
de un programa, se deberán dar detalles sobre la
manera en que la información se proporcionará al
programa.
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R A.7
A R P A.24
172 | Inicio de un Proyecto

Si se necesita un procedimiento formal de Algunas de éstas podrían haber sido ya

participación de las partes interesadas (tal como el
que se describe en el Capítulo 5), éste también se
deberá documentar como parte de la Estrategia
de Gestión de la Comunicación y debería dejar
constancia de los tipos de partes interesadas, las
relaciones deseadas y los mensajes principales,
así como de las estrategias para comunicación
y los métodos para evaluar el éxito de las
comunicaciones.
La Figura 14.5 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto para
comprender si el proyecto necesita aplicar
cualquier estrategia de gestión corporativa o del
programa, norma o práctica relacionadas con la
gestión de la comunicación
■■ Buscar lecciones de proyectos similares
anteriores, de la gestión corporativa o del
programa y de organizaciones externas
relacionadas con la gestión de la comunicación.
registradas en el Archivo sobre las Lecciones
■■ Revisar el Registro de Riesgos y el Registro
de Cuestiones para encontrar los riesgos y
las cuestiones asociados con la gestión de la
comunicación
■■ Identificar y/o revisar las partes interesadas y
consultarles para determinar sus necesidades de
información:
●● Identificar las relaciones deseadas
●● Aclarar los principales mensajes de
comunicación
●● Determinar los resultados finales deseados de
las comunicaciones exitosas
■■ Establecer las necesidades de información
asociadas con la Estrategia de Gestión de la
Calidad, la Estrategia de Gestión del Riesgo y la
Estrategia de Gestión de la Configuración
■■ Definir la Estrategia de Gestión de la
Comunicación, incluyendo:
●● El procedimiento de gestión de la
comunicación
●● Las herramientas y técnicas que se utilizarán

Expediente Preparar la (Parte de la)

Estrategia de Documentación de
del Proyecto Inicio del Proyecto
Gestión de la Comunicación

Crear Estrategia de
Archivo sobre Gestión de la
las Lecciones Comunicación

Registro de Riesgos

Registro de Cuestiones

(Parte de la )
Documentación de
Inicio del Proyecto

Estrategia de
Gestión del Riesgo

Estrategia de
Gestión de la Calidad

Estrategia de
Gestión de la
Configuración

Figura 14.5 Resumen de actividades para preparar la Estrategia de Gestión de la Comunicación


●●Los testimonios documentales que se
guardarán
●● La manera en que se informará sobre el
rendimiento del procedimiento de gestión de
la comunicación
●● La secuencia temporal de las actividades de
comunicación
●● Los roles y responsabilidades para las
actividades de comunicación
●● Análisis de las partes interesadas
■■ Consultar a la Garantía del Proyecto para
comprobar que la Estrategia de Gestión de
la Comunicación propuesta satisfaga las
necesidades de la Junta de Proyecto y/o de la
gestión corporativa o del programa
■■ Si se identifica cualquier riesgo o cuestión nuevos
(o si los existentes han cambiado), actualizar el
Registro de Riesgos, el Registro de Cuestiones y/o
el Archivo Diario
■■ Solicitar de la Junta de Proyecto la aprobación
de la Estrategia de Gestión de la Comunicación
(aunque la Junta de Proyecto podría preferir
revisar la misma más adelante como parte de la
Documentación de Inicio del Proyecto).
La Tabla 14.4 muestra las responsabilidades para
esta actividad.
Tabla 14.4 Responsabilidades para preparar la Estrategia de Gestión de la Comunicación
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa
Producto Acción
Estrategia de Gestión de la
Crear
Comunicación
Inicio de un Proyecto | 173
14.4.5 Establecer los controles del
proyecto
Es necesario convenir el nivel de control que la
Junta de Proyecto necesitará después del inicio del
proyecto y establecer el mecanismo para dichos
controles, así como el nivel de control que el
Project Manager necesitará ejercer sobre el trabajo
que los Team Managers llevarán a cabo.
Los controles del proyecto permiten la gestión
efectiva y eficiente del proyecto, de forma
coherente con la escala, el nivel de riesgo, la
complejidad y la importancia del proyecto.
Los controles efectivos del proyecto son un
prerrequisito de la gestión por excepción.
Los controles del proyecto pueden incluir:
■■ La frecuencia y el formato de la comunicación
entre los niveles de la gestión del proyecto
(véase el Capítulo 5)
■■ La cantidad de fases y por consiguiente de
evaluaciones al final de fases (véase el Capítulo 7)
■■ Los mecanismos para registrar y analizar
cuestiones y cambios (véase el Capítulo 9)
■■ Los mecanismos para presentar excepciones
(véase el Capítulo 10)
■■ Las tolerancias para la autoridad delegada
(véase el Capítulo 10)
■■ La manera en que se hará el seguimiento de la
autoridad delegada de un nivel de gestión a
otro (véase el Capítulo 10).
Descripción de Producto disponible
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R A.8
174 | Inicio de un Proyecto

Muchos de estos controles habrán sido definidos en
las estrategias para el proyecto pero no se habrán
necesariamente establecido. El elemento central de
esta actividad consiste en establecer tales controles
y asegurar que formen un conjunto coherente que
tenga sentido.
La Figura 14.6 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto para
comprender si el proyecto debe aplicar
cualquier estrategia de gestión corporativa o
del programa, norma o práctica relacionadas
con los controles. Identificar si cualquiera de
éstos requiere que PRINCE2 sea adaptado
■■ Revisar la Estrategia de Gestión de la Calidad,
la Estrategia de Gestión de la Configuración, la
Estrategia de Gestión del Riesgo y la Estrategia
de Gestión de la Comunicación para identificar
qué controles es necesario establecer
■■ Buscar lecciones de proyectos similares
anteriores, de la gestión corporativa o del
programa y de organizaciones externas
relacionadas con los controles del proyecto.
Algunas de éstas podrían haber sido ya
registradas en el Archivo sobre las Lecciones
■■ Revisar el Registro de Riesgos y el Registro
de Cuestiones para encontrar los riesgos y
las cuestiones asociados con los controles del
proyecto. El conjunto total de riesgos tendrá un
impacto en la escala y el rigor de las actividades
de control
■■ Confirmar y documentar la cantidad y la
ubicación de los límites de fase de gestión que

Archivo sobre (Parte de la)

Establecer los Documentación de
las Lecciones controles del proyecto Inicio del Proyecto

Expediente Crear Controles

del Proyecto del proyecto

Actualizar Descripciones
(Parte de la)
Documentación de de roles
Inicio del Proyecto

Actualizar Estructura del equipo

Estrategia de de gestión del proyecto
Gestión de la Calidad

Estrategia de
Gestión de la
Configuración

Estrategia de
Gestión del Riesgo

Estrategia de
Gestión de la
Comunicación

Plan de Proyecto

Registro de Riesgos

Registro de Cuestiones

Figura 14.6 Resumen de actividades para establecer los controles del proyecto

se requieren para proporcionar el nivel de
control apropiado
■■ Asignar los diversos niveles de toma de
decisiones requeridos en el proyecto al nivel de
gestión del proyecto más apropiado. Establecer
cualquier procedimiento de toma de decisiones
que pueda ser apropiado, posiblemente
mediante la adaptación de procedimientos
dentro de un sistema de gestión de la calidad
existente u otros procedimientos estándar
■■ Incorporar la autoridad y responsabilidad de la
toma de decisiones convenida a la estructura
del equipo de gestión del proyecto y las
descripciones de roles en los casos en que sea
apropiado; esto podría incluir ultimar cualquier
rol no previamente asignado, reasignar roles
previamente ocupados y, de ser necesario,
rediseñar el equipo de gestión del proyecto
■■ Confirmar las tolerancias para el proyecto y
los procedimientos para presentar excepciones
(de los Team Managers al Project Manager, del
Project Manager a la Junta de Proyecto y de la
Junta de Proyecto a la gestión corporativa o del
programa)
■■ Resumir los controles del proyecto en la
Documentación de Inicio del Proyecto
■■ Consultar a la Garantía del Proyecto para
comprobar que los controles del proyecto
propuestos sean consecuentes con la naturaleza
del proyecto y satisfagan las necesidades de la
Tabla 14.5 Responsabilidades para establecer los controles del proyecto
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Controles del proyecto Crear
Descripciones de roles Actualizar
Estructura del equipo de gestión del proyecto Actualizar
Inicio de un Proyecto | 175
Junta de Proyecto y/o de la gestión corporativa
o del programa
■■ Si se identifica cualquier riesgo o cuestión
nuevos (o si los existentes han cambiado),
actualizar el Registro de Riesgos, el Registro de
Cuestiones y/o el Archivo Diario
■■ Solicitar de la Junta de Proyecto la aprobación
de los controles del proyecto (la Junta de
Proyecto podría preferir revisar los mismos más
adelante como parte de la Documentación de
Inicio del Proyecto).
La Tabla 14.5 muestra las responsabilidades para
esta actividad.
14.4.6 Crear el Plan de Proyecto
Antes de comprometerse a realizar gastos de
importancia en el proyecto, se deberán establecer
las exigencias en cuanto a recursos y calendarios.
Esta información se incorpora en el Plan de
Proyecto y se requiere a fin de poder perfeccionar
el Business Case y de que la Junta de Proyecto
pueda controlar el proyecto.
La planificación no es una actividad que el Project
Manager realiza aisladamente sino, más bien,
algo que se debería realizar con la participación
directa de usuarios y proveedores. A menudo es
útil organizar talleres de planificación para ayudar
a identificar todos los productos requeridos, sus
detalles y las dependencias entre ellos.
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R
(A) (A) (A) P R
(A) (A) (A) P
176 | Inicio de un Proyecto

Para más información sobre planificación, véase el
Capítulo 7.
La Figura 14.7 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto a fin de:
●● Comprender aquello que el proyecto debe
entregar y comprobar si hay cualquier hito
predeterminado, según lo definido en el
Expediente del Proyecto
●● Comprobar si hay cualquier estrategia de
gestión corporativa o del programa, norma
o práctica relacionadas con la planificación,
que el proyecto deba cumplir
●● Comprobar la comprensión de cualquier
prerrequisito, dependencia externa,
restricción y suposición documentados en el
Expediente del Proyecto
●● Comprobar la comprensión de la solución
seleccionada, según la descripción del
enfoque del proyecto

(Parte de la)
Archivo sobre Crear el Documentación de
las Lecciones Plan de Proyecto Inicio del Proyecto

Crear Plan de
Registro de Riesgos Proyecto

Actualizar Estructura del

equipo de gestión
Registro de Cuestiones del proyecto

Actualizar Descripciones
Expediente del de roles
Proyecto

Actualizar Fichas de Elementos

Enfoque del proyecto de Configuración

Descripción del
Producto del Proyecto

(Parte de la)
Documentación de
Inicio del Proyecto

Estrategia de
Gestión de la Calidad

Estrategia de
Gestión de la
Configuración

Estrategia de
Gestión del
Riesgo

Estrategia de
Gestión de la
Comunicación

Controles del proyecto

Figura 14.7 Resumen de actividades para crear el Plan de Proyecto


■■ Buscar lecciones de proyectos similares
anteriores, de la gestión corporativa o del
programa y de organizaciones externas
relacionadas con la planificación. Algunas de
éstas podrían haber sido ya registradas en el
Archivo sobre las Lecciones
■■ Revisar el Registro de Riesgos y el Registro
de Cuestiones para encontrar los riesgos y las
cuestiones asociados con la planificación
■■ Decidir el formato y la presentación del Plan
de Proyecto, dado el público al cual el plan
está dirigido y la manera en que será utilizado
(por ejemplo, ¿es suficiente utilizar una lista
de productos para presentar el plan a la Junta
de Proyecto?). Para más información, véase
la Descripción de Producto para un plan en el
Apéndice A
■■ Identificar cualquier herramienta de
planificación y control a ser utilizada por el
proyecto
■■ Elegir el o los métodos para estimar los planes
del proyecto
■■ Revisar la Estrategia de Gestión de la Calidad,
la Estrategia de Gestión del Riesgo, la
Estrategia de Gestión de la Configuración y
la Estrategia de Gestión de la Comunicación
para comprender los recursos, las normas, los
métodos y los costes para el trabajo a realizar
Tabla 14.6 Responsabilidades para crear el Plan de Proyecto
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Plan de Proyecto Crear
Descripciones de Productos Crear
Fichas de Elementos de Configuración Crear/actualizar
Estructura del equipo de gestión del proyecto Actualizar
Descripciones de roles Actualizar
Inicio de un Proyecto | 177
■■ Crear una estructura jerárquica de productos,
un diagrama de flujo de los productos y
Descripciones de Productos para los productos
principales en el Plan de Proyecto. Identificar
los preparativos para la transición de los
productos del proyecto a su uso operacional. En
los casos en que es probable que los productos
del proyecto, una vez que estén en uso,
requieran mantenimiento se deberá organizar
potencialmente la redacción de un acuerdo o
contrato de servicio apropiado entre el grupo
de apoyo y el usuario. En tales casos será
necesario incluir cualquier acuerdo como un
producto en el Plan de Proyecto
■■ Considerar si es necesario actualizar la
Descripción del Producto del Proyecto (por
ejemplo, si ha cambiado la comprensión de
los criterios de aceptación o la misma ha sido
perfeccionada durante el transcurso del inicio
del proyecto)
■■ Crear o actualizar las Fichas de Elementos de
Configuración para cada producto que el plan
entregará
■■ Identificar y confirmar los recursos requeridos.
Confirmar la disponibilidad de las personas
seleccionadas, su aceptación de estos roles y su
compromiso a realizarlos. Para más información,
véase el Capítulo 5
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R A.22
(A) (A) (A) P R A.4
A R P A.12
(A) (A) (A) P R
(A) (A) (A) P R
178 | Inicio de un Proyecto
■■ Identificar las actividades, los recursos y
la secuencia temporal de los controles del
proyecto e incluirlos en el plan
■■ Identificar los riesgos asociados con el plan
■■ Documentar el Plan de Proyecto
■■ Consultar a la Garantía del Proyecto para
comprobar que el Plan de Proyecto propuesto
satisfaga las necesidades de la Junta de
Proyecto y/o de la gestión corporativa o del
programa
■■ Si se identifica cualquier riesgo o cuestión
nuevos (o si los existentes han cambiado),
actualizar el Registro de Riesgos, el Registro de
Cuestiones y/o el Archivo Diario
■■ Solicitar de la Junta de Proyecto la aprobación
del Plan de Proyecto (aunque la Junta de
Proyecto podría preferir revisar el mismo más
adelante como parte de la Documentación de
Inicio del Proyecto).
La Tabla 14.6 muestra las responsabilidades para
esta actividad.
14.4.7 Perfeccionar el Business Case
Es necesario actualizar el Business Case preliminar
producido durante la Puesta en Marcha de un
Proyecto a fin de que refleje el tiempo y los
costes previstos, según se determina en el Plan de
Proyecto, y la totalidad de los riesgos del Registro
de Riesgos actualizado.
La Junta de Proyecto utilizará el Business Case
detallado, que proporciona las bases para el
control continuo de la viabilidad del proyecto, para
autorizar el proyecto.
Expediente
del Proyecto
Business Case
(preliminar)
(Parte de la)
Documentación de
Inicio del Proyecto
Plan de Proyecto
Registro de Riesgos
Figura 14.8 Resumen de actividades para perfeccionar el Business Case
Para más información sobre la justificación
comercial, véase el Capítulo 4.
La Figura 14.8 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Expediente del Proyecto para
comprobar si hay cualquier exigencia de la
gestión corporativa o del programa en cuanto al
formato y contenido del Business Case
■■ Buscar lecciones de proyectos similares anteriores,
de la gestión corporativa o del programa y de
organizaciones externas relacionadas con el
desarrollo del Business Case. Algunas de éstas
podrían haber sido ya registradas en el Archivo
sobre las Lecciones
■■ Crear el Business Case detallado incorporando los
detalles adicionales obtenidos a partir de:
●● Los calendarios y los costes calculados en el
Plan de Proyecto
●● Los riesgos principales que afectan la
viabilidad y factibilidad del proyecto (del
Registro de Riesgos)
●● Los beneficios a obtener
●● Las tolerancias permitidas para cada uno de
los beneficios
■■ Crear el Plan de Revisión de Beneficios:
●● Revisar el Business Case y comprobar la
comprensión de los beneficios esperados del
proyecto
●● Identificar la manera en que se medirá el
logro de cada beneficio y medir la situación
baseline actual
Refinar el Crear Plan de
Business Case Revisión de Beneficios
(Parte de la)
Documentación de
Inicio del Proyecto
Crear Business Case
(detallado)

Identificar la secuencia temporal de las
●●
revisiones de los beneficios (más probable que
estén en línea con los límites de fase)
●● Si el proyecto es parte de un programa, el
Plan de Revisión de Beneficios se podrá crear,
mantener y ejecutar a nivel de programa
●● Si se identifica cualquier riesgo o cuestión
nuevos (o si los existentes han cambiado),
actualizar el Registro de Riesgos, el Registro
de Cuestiones y/o el Archivo Diario
■■ Consultar a la Garantía del Proyecto para
comprobar que el Business Case y el Plan de
Revisión de Beneficios propuestos satisfagan las
necesidades de la Junta de Proyecto y/o de la
gestión corporativa o del programa
■■ Solicitar de la Junta de Proyecto la aprobación
del Business Case y del Plan de Revisión de
Beneficios (aunque la Junta de Proyecto podría
preferir revisar los mismos más adelante
como parte de la Documentación de Inicio del
Proyecto).
La Tabla 14.7 muestra las responsabilidades para
esta actividad.
Tabla 14.7 Responsabilidades para perfeccionar el Business Case
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Plan de Revisión de Beneficios Crear
Business Case detallado Crear
Inicio de un Proyecto | 179
14.4.8 Preparar la Documentación de
Inicio del Proyecto
Es necesario que haya un punto central en el cual
toda la información relacionada con el “qué, por
qué, quién, cómo, dónde, cuándo y cuánto” del
proyecto:
■■ Se recopila para su aprobación por las partes
interesadas principales
■■ Está disponible para orientación e información
de quienes participan en el proyecto.
Esta información se elabora y recopila en la
Documentación de Inicio del Proyecto. La
Documentación de Inicio del Proyecto es una suma
de muchos de los productos de gestión creados
durante el inicio del proyecto y se utiliza para
obtener la autorización para que el proyecto
proceda. No es necesariamente un documento
único (y rara vez lo es), sino una colección de
documentos.
La versión de la Documentación de Inicio del
Proyecto creada durante el proceso del Inicio de
un Proyecto, y que se utiliza luego para obtener
la autorización para que el proyecto proceda,
se debería conservar. Se utilizará más adelante
como un medio para comparar el desarrollo real
del proyecto con las previsiones originales que
formaron la base de la aprobación.
La Figura 14.9 muestra los aportes y resultados
relativos a esta actividad.
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) (A) P R A.23
(R) (A) (A) (A) P R A.3
180 | Inicio de un Proyecto

Expediente Preparar la Documentación Preparar Documentación de

del Proyecto de Inicio del Proyecto Inicio del Proyecto

Definición del proyecto Solicitud de entrega

de un proyecto

Se acerca
el límite de fase
Enfoque del proyecto

Business
Business Case
Case
(detallado)
(detallado)

Estructura del equipo de

gestión del proyecto

Descripciones
Descripciones
Descripcionesde
de
deroles
roles
roles

Estrategia
Estrategiade
Estrategia de
de
Gestión
Gestión
Gestión dede
de
laCalidad
Calidad
Calidad

Estrategia de
Gestión de
la Configuración

Estrategia
Estrategia de
de
Gestión
Gestióndel
Gestión de Riesgo
de Riesgo

Estrategia de
Gestión de
la Comunicación

Plan
Plande
Plan de
deProyecto
Proyecto
Proyecto

Controles
Controles
Controlesdel
del
delproyecto
proyecto
proyecto

Adaptación
Adaptación
Adaptaciónde
de
de
PRINCE2
PRINCE2
PRINCE2

Figura 14.9 Resumen de actividades para preparar la Documentación de Inicio del Proyecto
 Inicio de un Proyecto | 181

PRINCE2 recomienda las siguientes acciones: ■■ Preparar la Documentación de Inicio del

■■ Extraer y, si es necesario, revisar la información
del Expediente del Proyecto (definición del
proyecto y enfoque del proyecto)
■■ Incluir o hacer referencia a información en:
●● La estructura del equipo de gestión del
proyecto y las descripciones de los roles
●● el Business Case
●● la Estrategia de Gestión de la Calidad
●● la Estrategia de Gestión de la Configuración
●● la Estrategia de Gestión del Riesgo
●● la Estrategia de Gestión de la Comunicación
●● el Plan de Proyecto
■■ Incluir o hacer referencia a los controles
del proyecto y resumir la manera en que el
proyecto ha adaptado PRINCE2
Proyecto
■■ Realizar una verificación de la información en
los diversos elementos para asegurar que sean
compatibles
■■ Consultar a la Garantía del Proyecto para
comprobar que la Documentación de Inicio del
Proyecto preparada satisfaga las necesidades
de la Junta de Proyecto y/o de la gestión
corporativa o del programa
■■ Prepararse para la fase siguiente (que activa el
proceso de la Gestión de los Límites de Fase)
■■ Solicitar autoridad de la Junta de Proyecto para
entregar el proyecto.
La Tabla 14.8 muestra las responsabilidades para
esta actividad.

Tabla 14.8 Responsabilidades para preparar la Documentación de Inicio del Proyecto

Productor – responsable de la producción del producto

Revisor – idealmente, independiente de la producción

Descripción de Producto disponible

Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Documentación de Inicio del Proyecto Preparar (A) (A) (A) P R A.6
 15
Control de una Fase
15 Control de una Fase

15.1 Propósito 15.2 Objetivo

El propósito del proceso del Control de una Fase El objetivo del proceso del Control de una Fase es
es asignar el trabajo que se debe realizar, hacer un asegurar que:
seguimiento de dicho trabajo, hacer frente a las
■■ Se centre la atención en la entrega de los
cuestiones, informar a la Junta de Proyecto sobre
productos de la fase. Se controle cualquier
el progreso y llevar a cabo rectificaciones para
desviación respecto de la dirección y los
garantizar que la fase se mantenga dentro de las
productos acordados al principio de la fase,
tolerancias establecidas.
para evitar que se den cambios incontrolados

Dirección de un Proyecto

Plan de Excepción
aprobado
Excepción Solicitud de Asesoramiento de
Autorización planteada asesoramiento
de fase la Junta de Proyecto

Gestión de los Cierre de

Límites de Fase un Proyecto

Se acerca el Se acerca el
límite de fase final del proyecto

Presentar excepciones Informar

Control relativas a sobre el
de una Fase cuestiones y riesgos desarrollo

Rectificar Revisar el
estado de la fase

Registrar y
examinar las Cuestión nueva
cuestiones y los riesgos

Autorizar un Revisar el estado Recibir el Paquete

Paquete de Trabajo del Paquete de Trabajo
de Trabajo completado

Autoridad para Paquete de Trabajo

entregar el Paquete completado
de Trabajo

Gestión de la Entrega de Productos

Figura 15.1 Visión general del Control de una Fase

186 | Control de una Fase
en el alcance del proyecto (scope creep) y que el
proyecto pierda su enfoque
■■ Se mantengan bajo control los riesgos y las
cuestiones
■■ Se revise regularmente el Business Case
■■ Se entreguen los productos acordados para la
fase, cumpliendo con las normas de calidad
establecidas, ajustándose a los costes, el
esfuerzo y el tiempo acordados y, en última
instancia, teniendo como fin el logro de los
beneficios definidos
■■ Se centre la atención del equipo de gestión del
proyecto en la entrega dentro de las tolerancias
establecidas.
15.3 Contexto
El proceso del Control de una Fase describe el
trabajo que el Project Manager realiza para la
gestión diaria de la fase. Este proceso se utilizará
para cada fase de entrega de un proyecto. Hacia el
final de cada fase, salvo la fase final, tendrán lugar
las actividades del proceso de la Gestión de los
Límites de Fase (véase el Capítulo 17).
Normalmente, el proceso del Control de una Fase
se utiliza por primera vez después de que la Junta
de Proyecto autorice el proyecto, pero se podría
optar por utilizarlo durante la fase de inicio para
proyectos grandes o complejos cuyo inicio dure
mucho tiempo.
Se utilizan los Paquetes de Trabajo para definir
y controlar el trabajo que se debe realizar, y
para determinar las tolerancias para el/los Team
Manager(s). En los casos en que el Project Manager
tenga a su vez el rol de Team Manager, también
se deben utilizar los Paquetes de Trabajo para
definir y controlar el trabajo de cada miembro del
equipo al que se asigne trabajo. En esos casos,
las referencias que se hagan al Team Manager en
todo el proceso del Control de una Fase se deben
considerar como referencias al miembro concreto
del equipo a quien se asigna trabajo.
El control diario del trabajo que se está realizando
es esencial para que un proyecto acabe teniendo
éxito. Durante una fase determinada, dicho control
consistirá en el siguiente ciclo:
■■ Autorizar el trabajo que se debe realizar
■■ Hacer un seguimiento de la información sobre
el progreso de dicho trabajo, incluyendo la
aceptación de Paquetes de Trabajo completados
■■ Revisar la situación (incluyendo la de la calidad
de los productos) y activar nuevos Paquetes de
Trabajo
■■ Informar sobre el desarrollo
■■ Prestar atención, evaluar y gestionar posibles
cuestiones y riesgos
■■ Llevar a cabo cualquier rectificación necesaria.
Hacia el final de la última fase se recurrirá al
proceso del Cierre de un Proyecto (véase el
Capítulo 18).
15.4 Actividades
Las actividades del proceso del Control de una Fase
están orientadas al Project Manager e incluyen:
■■ Paquetes de Trabajo:
●● Autorizar un Paquete de Trabajo
●● Revisar el estado del Paquete de Trabajo
●● Recibir el Paquete de Trabajo completado
■■ Seguimiento e información:
●● Revisar el estado de la fase
●● Informar sobre el desarrollo
■■ Cuestiones:
●● Registrar y examinar cuestiones y riesgos
●● Presentar excepciones relativas a cuestiones
y riesgos
●● Llevar a cabo rectificaciones
15.4.1 Autorizar un Paquete de Trabajo
No tendría sentido que cada una de las personas
que trabajan en un proyecto pudiera comenzar
actividades cuando le parezca conveniente. Debe
existir cierto grado de autonomía dentro del
equipo o equipos del proyecto, pero siempre
existirán ciertas circunstancias de las que no
tienen por qué tener conocimiento. Por lo tanto,
es importante que el trabajo comience y continúe
únicamente cuando se cuente con la autorización
del Project Manager. La producción, ejecución y
entrega de un Paquete de Trabajo es el vehículo
para ello.
Un Paquete de Trabajo puede incluir extractos
del Plan de Proyecto, Plan de la Fase o de
la Documentación de Inicio del Proyecto, o
simplemente referencias a éstos.
Un Paquete de Trabajo debería cubrir el trabajo
para crear uno o más productos. Si un producto
requiere más de un Paquete de Trabajo para su
creación, se deberá dividir en varios productos
 Control de una Fase | 187

Autorizar un Actualizar Plan de la Fase

Plan de la Fase
Paquete de Trabajo (fase en curso)

Descripciones Crear
de Productos Paquete(s) de Trabajo

(Parte de la) Actualizar Fichas de Elementos

de Configuración
Documentación de
Inicio del Proyecto

Actualizar
Registro de Calidad
Controles del proyecto

Actualizar
Estrategia de Registro de Riesgos
Gestión de la Calidad

Actualizar
Estrategia de Registro de Cuestiones
Gestión de
la Configuración

Autoridad para
Plan del Equipo entregar un Paquete
de Trabajo

Rectificación

Paquete de Trabajo
nuevo

Autorización
de fase

Plan de Excepción
aprobado

Figura 15.2 Resumen de actividades para autorizar un Paquete de Trabajo

adicionales con sus respectivas Descripciones de
Productos.
Los desencadenantes para que el Project Manager
autorice un Paquete de Trabajo incluyen:
■■ Autorización de fase – la Junta de Proyecto
autoriza la ejecución de un Plan de la Fase
■■ Aprobación de un Plan de Excepción – la Junta
de Proyecto autoriza la ejecución de un Plan de
Excepción
■■ Se requiere un nuevo Paquete de Trabajo –
resultado de revisar el estado de la fase (véase la
sección 15.4.4)
■■ Rectificación – en respuesta a una cuestión o un
riesgo.
Esta actividad se utiliza para autorizar
nuevos Paquetes de Trabajo o para autorizar
modificaciones a los ya existentes.
La Figura 15.2 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las acciones siguientes:
■■ Examinar el Plan de la Fase actual para
comprender:
●● Los productos que se deben crear
●● El coste y esfuerzo que se prevé que el
trabajo requerirá
●● Las tolerancias disponibles
■■ Examinar la Documentación de Inicio del
Proyecto para comprender:
188 | Control de una Fase

Los controles del proyecto requeridos (por

●●
ejemplo, los pasos para informar sobre el
progreso)
●● Las normas de calidad requeridas según lo
definido en la Estrategia de Gestión de la
Calidad
●● Si algún producto ha de ser entregado, la
manera en que esto se llevará a cabo (según
lo definido en la Estrategia de Gestión de la
Configuración)
■■ Definir cada Paquete de Trabajo que se deba
autorizar (o modificar)
●● Obtener las Descripciones de Productos
pertinentes para incluirlas en el Paquete de
Trabajo
●● Definir las técnicas, los procesos y los
procedimientos que se deben utilizar
●● Definir las interacciones de desarrollo que se
deben mantener
●● Definir las interacciones de uso y
mantenimiento que se deben mantener
●● Definir los requisitos de gestión de la
configuración
Definir los acuerdos conjuntos con respecto
●●
al esfuerzo, los costes, las fechas de comienzo
y finalización, los hitos principales y las
tolerancias
●● Definir cualquier restricción aplicable
●● Definir los pasos para presentar informes,
abordar problemas y presentar excepciones
●● Definir el método de aprobación
●● Facilitar las referencias pertinentes (por
ejemplo, Plan de la Fase o Descripciones de
Productos)
■■ Revisar el Paquete de Trabajo con el Team
Manager, asegurarse de que lo haya aceptado
y autorizarle a comenzar el trabajo (véase el
Capítulo 16)
■■ Revisar el Plan del Equipo del Team Manager
(o su resumen de hitos si debido a la relación
comercial es inapropiado que el Project
Manager vea su contenido) y actualizar el Plan
de la Fase para que refleje el calendario de
elaboración del Paquete o Paquetes de Trabajo
autorizados

Tabla 15.1 Responsabilidades para autorizar un Paquete de Trabajo

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Paquete de Trabajo Crear P (A) R A.21
Fichas de Elementos de Configuración Crear/actualizar A (R) R P A.12
Registro de Calidad Actualizar R (R) R P A.24
Registro de Riesgos Actualizar P A.26
Registro de Cuestiones Actualizar P A.25
Plan del Equipo Revisar R (P)

Plan de la Fase Actualizar P (R) R A.22

 Control de una Fase | 189

■■ Actualizar las Fichas de Elementos de 15.4.2 Revisar el estado del Paquete de

Configuración de modo que reflejen el
contenido del Paquete o Paquetes de Trabajo
autorizados
■■ Actualizar el Registro de Calidad en lo relativo
a las actividades de gestión de la calidad
planificadas. Consultar a la Garantía del
Proyecto para confirmar que los revisores
de calidad identificados y seleccionados son
aceptables
■■ Si es necesario, actualizar el Registro de Riesgos
de acuerdo con la Estrategia de Gestión del
Riesgo
■■ Si es necesario, actualizar el Registro de
Cuestiones.
La Tabla 15.1 muestra las responsabilidades para
esta actividad.
Trabajo
Esta actividad proporciona los medios necesarios
para evaluar regularmente el estado del Paquete
o Paquetes de Trabajo. La frecuencia y formalidad
de esta actividad irán normalmente en línea con la
frecuencia de los informes definida en el Paquete
o Paquetes de Trabajo y apoyada por el Plan de la
Fase actual.
La Figura 15.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones para
cada Paquete de Trabajo en desarrollo:
■■ Recopilar y revisar la información sobre el
progreso contenida en el Informe del Punto de
Control correspondiente al Paquete de Trabajo
en ejecución:
●● Evaluar el tiempo y el esfuerzo estimados
para completar cualquier trabajo no
finalizado (incluyendo cualquier trabajo no
iniciado todavía)

Revisar el estado del Actualizar

Plan de la Fase Plan de la Fase
Paquete de Trabajo

Actualizar Fichas de Elementos

Paquete(s) de Trabajo de Configuración

Actualizar
Informe(s) del Registro de Riesgos
Punto de Control

Actualizar
Registro de Cuestiones
Registro de Calidad

Actualizar
Paquete de Trabajo
Plan(es) del Equipo

Registro de Riesgos

Figura 15.3 Resumen de actividades para revisar el estado del Paquete de Trabajo
190 | Control de una Fase

●●Revisar el Plan del Equipo con el Team
Manager (o su resumen de hitos si debido
a la relación comercial es inapropiado que
el Project Manager vea su contenido) para
determinar si el trabajo se terminará a
tiempo y conforme al presupuesto
●● Revisar las anotaciones del Registro de
Calidad para comprender el estado actual de
las actividades de gestión de la calidad
●● Confirmar que la Ficha de un Elemento
de Configuración para cada producto del
Paquete de Trabajo está en conformidad a su
estado
■■ Si es necesario, actualizar el Registro de Riesgos
y el Registro de Cuestiones
■■ Actualizar el Plan de la Fase actual con datos
de la situación real hasta la fecha, previsiones y
ajustes.
La Tabla 15.2 muestra las responsabilidades para
esta actividad.
15.4.3 Recibir el Paquete de Trabajo
completado
Cuando se haya asignado trabajo a personas
o equipos, debería existir una confirmación
correspondiente cuando el trabajo ha sido
completado y aprobado.
Una vez aprobado, cualquier cambio posterior
realizado en el producto o productos debe pasar
por control de cambios (véase el Capítulo 9). Esto
debería ser un paso automático de cualquier
método de gestión de la configuración que se esté
utilizando.
La Figura 15.4 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Asegurarse de que el Team Manager haya
completado el trabajo definido por el Paquete o
Paquetes de Trabajo
■■ Verificar que las anotaciones del Registro
de Calidad relacionadas con el producto o
productos estén completas

Tabla 15.2 Responsabilidades para revisar el estado del Paquete de Trabajo

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Informe del Punto de Control Revisar R (P) A.18

Plan del Equipo Revisar R (P)

Plan de la Fase Actualizar P R A.22

Fichas de Elementos de Configuración Actualizar A (R) R P A.12

Registro de Riesgos Actualizar P A.26

Registro de Cuestiones Actualizar P A.25

 Control de una Fase | 191

Paquete de Trabajo Recibir el Paquete Actualizar Fichas de Elementos

completado de Trabajo completado de Configuración

Actualizar
Plan de la Fase Plan de la Fase

Registro de Calidad

Fichas de Elementos
de Configuración

Figura 15.4 Resumen de actividades para recibir los Paquetes de Trabajo completados

■■ Asegurarse de que cada producto del 15.4.4 Revisar el estado de la fase

Paquete de Trabajo haya obtenido la
aprobación requerida (como se define en las
responsabilidades de calidad de su Descripción
de Producto)
■■ Confirmar que la Ficha de un Elemento de
Configuración para cada producto aprobado
haya sido actualizada
■■ Actualizar el Plan de la Fase para que refleje el
Paquete de Trabajo como completado.
La Tabla 15.3 muestra las responsabilidades para
esta actividad.
Si no se comprueba el estado el proyecto con
frecuencia, existe el peligro de que se descontrole.
Por lo tanto, debe existir un equilibrio entre
la planificación previa y la respuesta a los
acontecimientos.
Para poder tomar decisiones bien fundadas
y ejercer un control racional, es necesario
comparar lo que ha sucedido en realidad con
lo que se esperaba que ocurriese y con lo que
podría ocurrir en el futuro (incluyendo cualquier
cuestión y riesgo). Por lo tanto, es esencial contar

Tabla 15.3 Responsabilidades para recibir el Paquete de Trabajo completado

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción

Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Fichas de Elementos de Configuración Confirmar A (R) R P A.12

Plan de la Fase Actualizar P R A.22

192 | Control de una Fase

continuamente con información que proporcione
una visión general del progreso y con sistemas de
seguimiento simples y fiables para proporcionar
dicha información.
El objetivo de esta actividad es, por lo tanto,
mantener una imagen precisa y actual del progreso
del trabajo que se está realizando y del estado de
los recursos.
Esta actividad tiene lugar normalmente con
la frecuencia definida en el Plan de la Fase.
También podría activarse como consecuencia del
asesoramiento recibido de la Junta de Proyecto
o como parte del análisis de nuevas cuestiones y
riesgos.
La Figura 15.5 muestra los aportes y resultados
relativos a esta actividad.

Plan de la Fase Revisar el

estado de la fase Rectificación

Amenaza a
las tolerancias
Registro de Calidad

Se acerca el
límite de fase
Informe sobre el
Estado de los Productos Se acerca el
final del proyecto

Informe(s) del Paquete de Trabajo

Punto de Control nuevo

Solicitud de
asesoramiento
Registro de Cuestiones

Actualizar
Registro de Riesgos

Registro de Riesgos

Actualizar
Registro de Cuestiones
Documentación de
Inicio del Proyecto

Actualizar
Plan de la Fase

Business Case

Actualizar Archivo sobre las

Lecciones

Plan de Proyecto

Actualizar
Informe de Cuestiones

Plan de Revisión
de Beneficios

Rectificación

Asesoramiento de la
Junta de Proyecto

Figura 15.5 Resumen de actividades para revisar el estado de la fase


PRINCE2 recomienda las siguientes acciones:
■■ Revisar el progreso de la fase:
●● Revisar los Informes del Punto de Control del
período correspondiente
●● Revisar el Plan de la Fase actual comparando
los pronósticos con la realidad
●● Solicitar un Informe sobre el Estado de
los Productos al Apoyo al Proyecto para
identificar posibles diferencias entre el
progreso planificado, el progreso reflejado
en informes y el progreso real
●● Comprobar si existen cuestiones de calidad
reflejadas en el Registro de Calidad
●● Comprobar en el Registro de Riesgos si
existen riesgos nuevos o revisados y evaluar
su impacto en el Business Case, el Plan de la
Fase o el Plan de Proyecto.
●● Comprobar el Registro de Cuestiones para
ver si ha sucedido algo dentro o fuera del
proyecto que vaya a afectar al Business Case,
al Plan de la Fase o al Plan de Proyecto
●● Comprobar el estado de las rectificaciones
●● Evaluar el uso de los recursos durante
el período que se está revisando y su
disponibilidad para el resto de la fase (o del
proyecto). Comprobar si existen cambios en
la disponibilidad de los recursos prevista para
el futuro
●● Comprobar el Plan de Revisión de Beneficios
para ver si se deben realizar revisiones de
beneficios y, de ser así, ejecutarlas como
corresponda
■■ En base al anterior análisis, decidir si se debe
llevar a cabo alguna acción. Por ejemplo, decidir
si se hace lo siguiente:
●● Autorizar un Paquete de Trabajo (sección
15.4.1)
●● Informar sobre el desarrollo (sección 15.4.5),
si lo requiere la Estrategia de Gestión de la
Comunicación
●● Registrar y examinar cuestiones y riesgos
(sección 15.4.6)
●● Presentar excepciones (sección 15.4.7),
en el caso de que las tolerancias se vean
amenazadas
●● Llevar a cabo rectificaciones (sección 15.4.8)
●● Pedir asesoramiento a la Junta de Proyecto
(y, si es necesario, facilitar a la Junta el
Informe de Cuestiones)
Control de una Fase | 193
●● Registrar las lecciones aprendidas que se
hayan identificado
●● Seguir adelante según lo planificado
■■ Revisar el Registro de Riesgos y el Registro de
Cuestiones si es necesario
■■ Actualizar el Plan de la Fase si la evaluación
agregada modifica las previsiones
■■ Si la propiedad de cualquiera de los productos
debe transferirse al cliente como parte de una
entrega por fases:
●● Solicitar un Informe sobre el Estado de los
Productos respecto de la release que se vaya
a entregar
●● Asegurarse de que:
●● Los productos hayan sido aprobados por
las personas indicadas en su Descripción
de Producto
●● Los productos cumplan con todos los
criterios de calidad o estén cubiertos por
concesiones aprobadas
●● Las organizaciones de uso y
mantenimiento estén preparadas para
asumir la responsabilidad de los productos
●● Entregar los productos (véase el Capítulo 18)
■■ Considerar si se revisan las lecciones en este
momento o si se espera a otra revisión del
estado de la fase en el futuro o a cuando se esté
acercando el final de la fase
■■ Si se acerca el final de la fase actual (porque
así lo indica, por ejemplo, el Plan de la Fase,
el contenido del Registro de Calidad, un hito,
etc.), prepararse para la siguiente fase (véase el
Capítulo 17)
■■ Si se acerca el final de la fase final, prepararse
para cerrar el proyecto (véase el Capítulo 18).
La Tabla 15.4 muestra las responsabilidades para
esta actividad.
194 | Control de una Fase
Tabla 15.4 Responsabilidades para revisar el estado de la fase
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Registro de Riesgos Actualizar
Registro de Cuestiones Actualizar
Plan de la Fase Actualizar
Archivo sobre las Lecciones Actualizar
Informe de Cuestiones Actualizar
15.4.5 Informar sobre el desarrollo
El Project Manager debe proporcionar a la
Junta de Proyecto información básica sobre el
estado de la fase y del proyecto y hacer llegar
otra información a las partes interesadas con la
frecuencia establecida en la Estrategia de Gestión
de la Comunicación (definida por la Junta de
Proyecto). Para más información sobre los controles
del progreso, véase el Capítulo 10.
La Figura 15.6 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Preparar la información de los Informes del
Punto de Control, el Registro de Riesgos, el
Registro de Cuestiones, el Registro de Calidad, el
Archivo sobre las Lecciones, el Informe sobre el
Estado de los Productos y cualquier modificación
importante del Plan de la Fase para el período
de informe actual (la información se obtiene
de la actividad de revisar el estado de la fase –
véase la sección 15.4.4)
■■ Preparar una lista de rectificaciones (anotadas
en el Archivo Diario y/o recogidas en el Registro
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
P A.26
P A.25
P R A.22
P A.1
P A.15
de Cuestiones) realizadas durante el período
de informe. Esto servirá, por ejemplo, para que
la Junta de Proyecto pueda comprobar que el
Project Manager está actuando dentro de las
tolerancias acordadas (la información se obtiene
de la actividad de llevar a cabo rectificaciones –
véase la sección 15.4.8)
■■ Revisar el Informe de Desarrollo del período de
informe anterior
■■ Elaborar el Informe de Desarrollo del período de
informe actual
■■ Distribuir el Informe de Desarrollo a la Junta
de Proyecto y a cualquier otro destinatario
indicado en la Estrategia de Gestión de la
Comunicación.
La Tabla 15.5 muestra las responsabilidades para
esta actividad.
 Control de una Fase | 195

Informe(s) del Informar sobre Crear Informe de Desarrollo

Punto de Control el desarrollo (período en curso)

Registro de Riesgos

Registro de Cuestiones

Registro de Calidad

Archivo sobre las

Lecciones

Informe sobre el
Estado de los Productos

Plan de la Fase

Archivo Diario

Informe de Desarrollo
(período anterior)

Documentación de
Inicio del Proyecto

Estrategia de
Gestión de
la Comunicación

Figura 15.6 Resumen de actividades para informar sobre el desarrollo

196 | Control de una Fase
Tabla 15.5 Responsabilidades para informar sobre el desarrollo
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa
Producto Acción
Informe de Desarrollo Crear
15.4.6 Registrar y examinar cuestiones
y riesgos
Durante la gestión del proyecto surgirán varias
cuestiones y pueden detectarse riesgos. Llegarán
de modo puntual y deberán registrarse de manera
organizada y efectiva. Cualquier miembro del
equipo del proyecto, de la gerencia corporativa o
del programa, así como otras partes interesadas,
pueden plantear una cuestión o riesgo.
Antes de tomar una decisión sobre los pasos a
seguir, se debe registrar cada cuestión o riesgo y a
continuación se debe evaluar su impacto.
Para más información sobre gestión del riesgo,
véase el Capítulo 8.
Para más información sobre los procedimientos de
control de cambios y cuestiones, véase el
Capítulo 9.
La Figura 15.7 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Si el Project Manager puede hacer frente a
una cuestión de modo informal, debe hacerlo
de ese modo e incluir una anotación en el
Archivo Diario (véase el Capítulo 9 para más
información)
■■ Para las cuestiones a las que se deba hacer
frente de modo formal (véase el Capítulo 9 para
más información):
Descripción de Producto disponible
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
P R A.16
Comprobar los requisitos del procedimiento
●●
de control de cambios y cuestiones en la
Estrategia de Gestión de la Configuración
●● Incluir la cuestión en el Registro de
Cuestiones tan pronto como sea registrada
●● Clasificar la cuestión (determinar si es una
solicitud de cambio, fuera de especificación o
un problema/asunto)
●● Evaluar la gravedad de la cuestión
●● Evaluar la prioridad de la cuestión
(para solicitudes de cambio y fuera de
especificación)
●● Evaluar el impacto de la cuestión en el Plan
de la Fase, el Plan de Proyecto y el Business
Case
●● Documentar la cuestión mediante la
elaboración de un Informe de Cuestiones
●● Informar sobre el estado de la cuestión de
acuerdo con la Estrategia de Gestión de la
Configuración y comprobar la Estrategia de
Gestión de la Comunicación para ver si existe
alguien externo que deba ser informado
sobre la cuestión
■■ Para los riesgos (véase el Capítulo 8 para más
información):
●● Comprobar los requisitos del procedimiento
de gestión del riesgo en la Estrategia de
Gestión del Riesgo
●● Incluir el riesgo en el Registro de Riesgos tan
pronto como sea registrado
●● Identificar el acontecimiento que concretaría
el riesgo y describir sus causas y efectos
 Control de una Fase | 197

Registrar y examinar Actualizar

Cuestión nueva cuestiones y riesgos Archivo Diario

Riesgo nuevo Crear

Informe de
Cuestiones

Plan de la Fase Actualizar

Registro de
Cuestiones

Documentación de
Inicio del Proyecto Actualizar Registro de
Riesgos

Business Case Solicitud de

asesoramiento

Plan de Proyecto

Estrategia de
Gestión de
la Comunicación

Estrategia de
Gestión de
la Configuración

Figura 15.7 Resumen de actividades para registrar y examinar cuestiones y riesgos

●●Evaluar el riesgo teniendo en cuenta la

información disponible en el Plan de la
Fase, el Plan de Proyecto y el Business Case y
planificar la respuesta al riesgo escogida
●● Informar sobre el estado del riesgo de
acuerdo con la Estrategia de Gestión del
Riesgo y comprobar la Estrategia de Gestión
de la Comunicación para ver si existen partes
externas que deban ser informadas sobre el
riesgo
■■ Antes de eligir el camino adecuado, revisar
primero el estado de la fase para contar con
una visión general, tanto si se trata de llevar a
cabo rectificaciones, de pedir asesoramiento a la
Junta de Proyecto como si se trata de plantear
una excepción sea relativa a una cuestión o un
riesgo (véase la sección 15.4.4).
La Tabla 15.6 muestra las responsabilidades para
esta actividad.
198 | Control de una Fase
Tabla 15.6 Responsabilidades de registrar y examinar cuestiones y riesgos
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Archivo Diario Actualizar
Informe de Cuestiones Crear
Registro de Cuestiones Actualizar
Registro de Riesgos Actualizar
15.4.7 Presentar excepciones relativas a
cuestiones y riesgos
Las tolerancias acordadas con la Junta de Proyecto
no se deben superar en ninguna fase. El Project
Manager solamente puede llevar a cabo una
rectificación o mantener las cosas como están
cuando se prevea que la fase (o el proyecto) se van
a completar dentro de las tolerancias establecidas
por la Junta de Proyecto. Esta actividad se utiliza
cuando las rectificaciones bajo el control del Project
Manager no servirían para evitar que la fase (o
el proyecto) exceda las tolerancias acordadas. Se
aplica a todos los tipos de cuestión y riesgo (o
conjunto de los mismos) que no se pueden resolver
dentro de las tolerancias fijadas por la Junta de
Proyecto.
Como reunir la información para elaborar un
Informe de Excepción puede llevar cierto tiempo,
se recomienda avisar a la Junta de Proyecto lo
antes posible. Por lo tanto, podría ser conveniente
que el Project Manager realizara esta actividad
en dos pasos: primero una notificación inicial
a la Junta de Proyecto con previsiones sobre la
situación de excepción que permitan a la Junta
estar preparada, y, a continuación, proporcionar
información adicional en forma de Informe de
Excepción.
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
P A.2
P A.15
P A.25
P A.26
El Project Manager debe ejecutar cualquier
decisión que la Junta de Proyecto emita en
respuesta a la presentación de la excepción.
La presentación de excepciones es una buena
práctica y no debe percibirse como un fracaso.
Cuanto antes se presenten a la Junta de Proyecto
las cuestiones o riesgos que amenazan la
situación, más tiempo habrá para llevar a cabo
rectificaciones.
Para más información sobre gestión del riesgo,
véase el Capítulo 8.
Para más información sobre los procedimientos de
control de cambios y cuestiones, véase el Capítulo 9.
Para más información sobre gestión de
excepciones, véase el Capítulo 10.
La Figura 15.8 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Examinar el Plan de la Fase para determinar el
nivel de desviación y los productos inacabados
y para deducir lo que ocurriría si se permitiera
que la desviación continuara
■■ Examinar el Plan de Proyecto para determinar
el estado del proyecto y el efecto general de
cualquier desviación (utilizando la versión
baseline actual de la Documentación de Inicio
del Proyecto).
 Control de una Fase | 199

Presentar excepciones Crear

Amenaza a Informe de Excepción
relativas a
las tolerancias
cuestiones y riesgos

Actualizar
Documentación de Registro de Cuestiones
Inicio del Proyecto

Actualizar
Registro de Riesgos
Business Case

Excepción
planteada
Plan de Proyecto

Actualizar
Informe de Cuestiones

Plan de la Fase
(fase en curso)

Informe de Cuestiones

Registro de Cuestiones

Registro de Riesgos

Figura 15.8 Resumen de actividades para presentar excepciones relativas a cuestiones y riesgos

■■ Determinar las opciones de recuperación y ●●Aumentar las tolerancias que se prevé

evaluarlas teniendo en cuenta el Business Case exceder
■■ Evaluar el impacto de las opciones de ●● Dar instrucciones al Project Manager para
recuperación teniendo en cuenta el Plan de la que elabore un Plan de Excepción, indicando
Fase actual. Se debe considerar la disponibilidad lo que será aceptable (véase el Capítulo 17)
de personas o grupos de personas con las ●● Dar instrucciones al Project Manager para
competencias o experiencia necesarias para cerrar el proyecto prematuramente (véase el
evaluar el impacto Capítulo 18).
■■ Incluir la descripción de la situación, las opciones La Tabla 15.7 muestra las responsabilidades para
y la recomendación a la Junta de Proyecto sobre esta actividad.
los pasos a seguir en un Informe de Excepción.
A continuación, la Junta de Proyecto tomará
una decisión sobre las medidas apropiadas (que
pueden coincidir o no con la recomendación del
Project Manager). La decisión puede incluir:
●● Solicitar más información o más tiempo para
considerar su respuesta
●● Aprobar, postergar o rechazar una solicitud
de cambio
●● Otorgar una concesión para un fuera de
especificación, postergarlo o rechazarlo
200 | Control de una Fase

Tabla 15.7 Responsabilidades para presentar excepciones relativas a cuestiones y riesgos

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Informe de Excepción Crear (A) (R) (R) P R A.17

Registro de Cuestiones Actualizar P A.25

Registro de Riesgos Actualizar P A.26

Informe de Cuestiones Actualizar P A.15

15.4.8 Llevar a cabo rectificaciones ■■ Activar la rectificación mediante la autorización

Los cambios y ajustes en el proyecto necesitan de un Paquete de Trabajo (véase la sección
realizarse con cuidado y de forma racional, incluso 15.4.1)
si parece que su gestión va a ser fácil y que no se ■■ Actualizar las Fichas de Elementos de
van a exceder las tolerancias. Configuración de los productos afectados
■■ Actualizar el Informe de Cuestiones (si es
Al llevar a cabo rectificaciones, el objetivo es
necesario) para reflejar el estado de la
seleccionar y, dentro de los límites de las tolerancias
rectificación
de la fase y del proyecto, llevar a cabo acciones que
■■ Actualizar el Registro de Cuestiones con los
resolverán las desviaciones respecto del plan. Las
cambios que resulten de la rectificación (o, si se
rectificaciones se activan durante la revisión del
está gestionando de modo informal, actualizar
estado de la fase (sección 15.4.4) y normalmente
el Archivo Diario con los datos y el estado de la
implican trabajar en base al asesoramiento y
rectificación)
orientación de la Junta de Proyecto y gestionar las
cuestiones planteadas por los Team Managers. ■■ Actualizar el Registro de Riesgos con los cambios
que resulten de la rectificación
Para más información sobre planificación, véase el ■■ Actualizar el Plan de la Fase actual.
Capítulo 7. Para más información sobre cuestiones
y control de cambios, véase el Capítulo 9. La Tabla 15.8 muestra las responsabilidades para
esta actividad.
La Figura 15.9 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Reunir toda la información pertinente sobre
la desviación (obteniéndola de las Fichas de
Elementos de Configuración, el Registro de
Cuestiones, el Registro de Riesgos, el Informe
de Excepción, el asesoramiento de la Junta de
Proyecto, el Archivo Diario)
■■ Identificar las posibles formas de gestionar la
desviación y seleccionar la opción más adecuada
 Control de una Fase | 201

Archivo Diario Actualizar Archivo Diario

Rectificar

Registro Actualizar Registro

de Cuestiones de Cuestiones

Actualizar Registro
Registro de Riesgos
de Riesgos

Actualizar Informe
de Cuestiones
Informe
de Cuestiones

Actualizar Plan de la Fase

Plan de la Fase

Fichas de Elementos
Actualizar de Configuración
Fichas de Elementos
de Configuración

Rectificación
Rectificación

Figura 15.9 Resumen de actividades para llevar a cabo rectificaciones

202 | Control de una Fase

Tabla 15.8 Responsabilidades de llevar a cabo rectificaciones

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Registro de Cuestiones Actualizar P A.25

Registro de Riesgos Actualizar P A.26

Informe de Cuestiones Actualizar P R A.15

Plan de la Fase Actualizar P R A.22

Fichas de Elementos de Configuración Actualizar P (R) R A.12

Archivo Diario Actualizar P A.2

 16
Gestión de la Entrega
de Productos
16 Gestión de la Entrega de Productos
16.1 Propósito
El propósito del proceso de la Gestión de la
Entrega de Productos es controlar la conexión
entre el Project Manager y el/los Team Manager(s)
mediante el establecimiento de requisitos formales
para la aceptación, ejecución y entrega del trabajo
del proyecto.
El rol de cada Team Manager es coordinar un área
de trabajo desde la que se llevará a cabo la entrega
de uno o más de los productos del proyecto.
Pueden formar parte de la organización del cliente
o ser externos a la misma.
16.2 Objetivo
El objetivo del proceso de la Gestión de la Entrega
de Productos es asegurarse de que:
■■ Se autorice y acuerde el trabajo relativo a los
productos asignados al equipo
■■ Los Team Managers, los miembros del equipo
y los proveedores tengan claro qué se debe
producir y cuáles son el nivel de esfuerzo, los
costes y los calendarios previstos
■■ Los productos planificados se entreguen
cumpliendo con las expectativas y dentro de las
tolerancias
■■ Se proporcione al Project Manager, con la
frecuencia acordada, información precisa
sobre el progreso para asegurarse de que se
gestionen las expectativas.
Control de una Fase
Autoridad para
entregar un
Paquete de Trabajo
Aceptar un
Paquete de Trabajo
Gestión de la Entrega de Productos
Figura 16.1 Visión general del proceso de la Gestión de la Entrega de Productos
16.3 Contexto
El proceso de la Gestión de la Entrega de Productos
contempla el proyecto desde la perspectiva del
Team Manager, mientras que el proceso del Control
de una Fase lo contempla desde la perspectiva del
Project Manager.
El Team Manager se asegura de que el equipo crea
los productos y los entrega al proyecto, mediante
las siguientes acciones:
■■ Aceptar y comprobar los Paquetes de Trabajo
autorizados, facilitados por el Project Manager
■■ Asegurarse de que se mantengan las
interacciones identificadas en el Paquete de
Trabajo
■■ Crear un Plan de Equipo para los Paquetes de
Trabajo que se asignen (es posible que esto
pueda hacerse mientras el Project Manager
prepara el Plan de la Fase durante la gestión de
los límites de fase)
■■ Asegurarse de que los productos se desarrollen
de acuerdo con los métodos especificados en el
Paquete de Trabajo
■■ Demostrar que cada producto cumple con
sus criterios de calidad mediante el método
o métodos de calidad especificados en la
Descripción de Producto – esto puede incluir la
utilización de la técnica de revisión de calidad
de PRINCE2 (véase el Capítulo 6)
Paquete de
Trabajo
completado
Ejecutar un Entregar un
Paquete de Trabajo Paquete de Trabajo
206 | Gestión de la Entrega de Productos
■■ Obtener la aprobación para los productos
completados de las autoridades identificadas en
la Descripción de Producto
■■ Entregar los productos al Project Manager de
acuerdo con los eventuales procedimientos que
se hayan especificado en el Paquete de Trabajo.
Si el proyecto hace uso de proveedores externos
que no utilizan PRINCE2, el proceso de la Gestión
de la Entrega de Productos proporciona una
explicación de la interacción necesaria entre el
Team Manager y el método de PRINCE2 que el
Project Manager esté utilizando para el proyecto. El
Paquete de Trabajo puede ser parte de un acuerdo
contractual. Por lo tanto, el grado de formalidad de
un Plan de Equipo puede variar desde sencillamente
adjuntar un anexo al Paquete de Trabajo hasta
crear un plan completo presentado en un formato
similar al de un Plan de la Fase.
Autoridad para Aceptar un
entregar un Paquete Paquete de Trabajo
de Trabajo
Paquete de Trabajo
Documentación de
Inicio del Proyecto
Figura 16.2 Resumen de actividades para aceptar un Paquete de Trabajo
16.4 Actividades
Las actividades del proceso de la Gestión de la
Entrega de Productos están orientadas al Team
Manager e incluyen:
■■ Aceptar un Paquete de Trabajo
■■ Ejecutar un Paquete de Trabajo
■■ Entregar un Paquete de Trabajo.
16.4.1 Aceptar un Paquete de Trabajo
El principio fundamental es que antes de que se
asigne un Paquete de Trabajo a un equipo, debe
existir un acuerdo entre el Project Manager y el
Team Manager sobre lo que se debe entregar,
los requisitos de presentación de informes, las
restricciones aplicables, los procedimientos que se
deben emplear y si las exigencias del Paquete de
Trabajo son razonables y se pueden alcanzar.
La Figura 16.2 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Paquete de Trabajo:
●● Obtener la documentación a la que se haga
referencia
●● Aclarar con el Project Manager lo que se
debe entregar
●● Negociar con el Project Manager, en nombre
del equipo, las restricciones aplicables a la
realización del trabajo
●● Acordar tolerancias para el Paquete de
Trabajo
●● Entender los requisitos de presentación de
informes
Crear Plan del Equipo
Actualizar Registro de Calidad
Aprobar Paquete de Trabajo
Plantear
Riesgo nuevo
 Gestión de la Entrega de Productos | 207

●●Entender de quién y de qué modo se debe
obtener la aprobación del producto o
productos
●● Entender cómo se debe realizar la entrega
formal del producto o productos aprobados
●● Confirmar cómo se debe informar al Project
Manager de que se ha completado el
Paquete de Trabajo
■■ Preparar un Plan de Equipo para mostrar que
el producto o productos pueden completarse
respetando las restricciones establecidas.
Consultar a la Garantía del Proyecto (proveedor)
para determinar si el Plan de Equipo es viable
y está conforme a las normas del proveedor
pertinentes. Solicitar la aprobación necesaria
para el Plan de Equipo (aunque si la relación
cliente/proveedor es de carácter comercial
podría ser inapropiado que el Project Manager
revise y apruebe el Plan de Equipo, y en ese
caso los hitos principales se resumirán en el
Paquete de Trabajo. En un contexto comercial,
los Planes de Equipo pueden ser revisados y
aprobados por el Proveedor Principal)
■■ Llevar a cabo una revisión de los riesgos
tomando como referencia el Plan de Equipo
e informar al Project Manager de cualquier
riesgo adicional o modificado (y si el Paquete
de Trabajo permite al Team Manager registrar
directamente los riesgos, el Team Manager
debería actualizar el Registro de Riesgos)
■■ Consultar a la Garantía del Proyecto para
determinar si se necesitan revisores adicionales
y, en ese caso, asegurarse de que se actualice
el Registro de Calidad (será necesario consultar
la información en el Paquete de Trabajo para
averiguar el procedimiento a utilizar para
actualizar el Registro de Calidad)

Tabla 16.1 Responsabilidades para aceptar un Paquete de Trabajo

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Plan del Equipo Crear (A) (A) P R

Riesgo Plantear (R) P

Registro de Calidad Actualizar (R) R (P) A.24

Paquete de Trabajo Aprobar (P) A R A.21
208 | Gestión de la Entrega de Productos

■■ Acordar la entrega del Paquete de Trabajo.
La Tabla 16.1 muestra las responsabilidades para
esta actividad.
16.4.2 Ejecutar un Paquete de Trabajo
Se ha de ejecutar y hacer un seguimiento del
trabajo de acuerdo con los requisitos definidos en
el Paquete de Trabajo autorizado.
Durante el desarrollo de los productos, el Team
Manager no debe superar las tolerancias del
Paquete de Trabajo acordadas con el Project
Manager. El Team Manager solamente puede
seguir adelante con el Paquete de Trabajo o
realizar rectificaciones cuando se prevea que el
Paquete de Trabajo será completado dentro de las
tolerancias establecidas por el Project Manager. En
el momento en que se prevea que se van a exceder
las tolerancias del Paquete de Trabajo, el Team
Manager debe plantear una cuestión al Project
Manager, que decidirá sobre los pasos a seguir.
La Figura 16.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Gestionar el desarrollo de los productos exigidos:
●● Desarrollar el producto o productos exigidos
por el Paquete de Trabajo, cumpliendo con los
criterios de calidad definidos en la Descripción de
Producto correspondiente
●● Asegurarse de que el trabajo se lleve a
cabo de acuerdo con las técnicas, procesos y
procedimientos especificados en el Paquete de
Trabajo
●● Mantener las interacciones de desarrollo y de
uso y mantenimiento detalladas en el Paquete
de Trabajo
●● Consultar en el Paquete de Trabajo el
procedimiento para actualizar el Registro de
Calidad (por ejemplo, anotar las actividades de
gestión de la calidad completadas)
●● Identificar y registrar el esfuerzo que ha sido
necesario

Ejecutar un Crear Producto(s)

Paquete de Trabajo Paquete de Trabajo especializado(s)

Actualizar Registro de Calidad

Plan del Equipo

Actualizar Fichas de Elementos

Documentación de de Configuración
Inicio del Proyecto

Actualizar Plan del Equipo

Crear Informe(s) del

Punto de Control

Obtener Ficha(s)
de aprobación

Plantear
Riesgo nuevo

Plantear
Cuestión nueva

Figura 16.3 Resumen de actividades para ejecutar un Paquete de Trabajo

 Gestión de la Entrega de Productos | 209

●●Hacer un seguimiento y control de cualquier ●● Actualizar el Plan de Equipo y, si es necesario,

cuestión o riesgo asociado al Paquete de Trabajo consultar a la Garantía del Proyecto (proveedor)
e informar al Project Manager sobre su estado sobre su viabilidad
■■ Notificar al Project Manager cualquier nueva ●● Informar al Project Manager sobre el progreso
cuestión, riesgo o lección. El Project Manager podrá mediante Informes del Punto de Control, de
entonces decidir los pasos apropiados a seguir. la manera y con la frecuencia indicadas en el
Adoptar las medidas requeridas por el Project Paquete de Trabajo
Manager
■■ Obtener las aprobaciones de los productos
completados:
●● Consultar en el Paquete de Trabajo el método
para obtener la aprobación y aplicarlo para
emitir fichas de aprobación
●● Consultar en el Paquete de Trabajo el
procedimiento para actualizar las Fichas de
Elementos de ConFiguración (para cambiar
el estado de los productos que se hayan
completado) y aplicar dicho procedimiento
■■ Revisar el estado del Paquete de Trabajo e informar
sobre el mismo al Project Manager:
●● Determinar el estado de cada producto del
Paquete de Trabajo

Tabla 16.2 Responsabilidades para ejecutar un Paquete de Trabajo

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Productos especializados Crear (A) (A) (A) (R) P R

Registro de Calidad Actualizar (R) R (P) A.24

Fichas de Elementos de Configuración Actualizar P P A.12

Plan del Equipo Actualizar P R

Informe del Punto de Control Crear (R) P A.18

Cuestión Plantear (R) P

Riesgo Plantear (R) P

Fichas de aprobación Obtener (R) P R R

210 | Gestión de la Entrega de Productos

Entregar un Actualizar
Paquete de Trabajo Paquete de Trabajo
Paquete de Trabajo

Actualizar Plan del Equipo

Registro de Calidad

Paquete de Trabajo
Fichas de Elementos completado
de Configuración

Figura 16.4 Resumen de actividades para entregar un Paquete de Trabajo

●● Si se prevé que se van a exceder las tolerancias
acordadas para el Paquete de Trabajo, notificarlo
al Project Manager planteando una cuestión.
La Tabla 16.2 muestra las responsabilidades para esta
actividad.
16.4.3 Entregar un Paquete de Trabajo
Del mismo modo que se aceptó el Paquete de
Trabajo del Project Manager, se debe informar
al Project Manager cuando el mismo se ha
completado.
La Figura 16.4 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el Registro de Calidad para verificar
que se han completado todas las actividades de
calidad relacionadas con el Paquete de Trabajo
■■ Revisar las fichas de aprobación para verificar
que se han aprobado todos los productos que
se deben entregar como parte del Paquete de
Trabajo
■■ Actualizar el Plan de Equipo para reflejar que el
Paquete de Trabajo ha sido completado
■■ Consultar en el Paquete de Trabajo el
procedimiento para entregar los productos
completados y seguir dicho procedimiento.
Notificar al Project Manager que el Paquete de
Trabajo ha sido completado.
La Tabla 16.3 muestra las responsabilidades para
esta actividad.

Tabla 16.3 Responsabilidades para entregar un Paquete de Trabajo

Productor – responsable de la producción del producto
Descripción de Producto disponible

Revisor – idealmente, independiente de la producción

Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Paquete de Trabajo Actualizar (A) P R A.21

Plan del Equipo Actualizar (R) P R

 17
Gestión de los
Límites de Fase
17 Gestión de los Límites de Fase

17.1 Propósito de los riesgos. Por lo tanto, el proceso se debe

El propósito del proceso de la Gestión de los
Límites de Fase es posibilitar que la Junta de
Proyecto reciba información suficiente por parte
del Project Manager para que pueda revisar el
desarrollo satisfactorio de la fase actual, aprobar
el Plan de la Fase siguiente, revisar el Plan de
Proyecto actualizado y confirmar la vigencia de la
justificación comercial continua y la aceptabilidad
ejecutar cuando el final de la fase de gestión en
curso sea inminente.
Los proyectos no siempre se desarrollan según
lo previsto y, como respuesta a un Informe de
Excepción (si se prevé que se van a exceder las
tolerancias de la fase o del proyecto), la Junta de
Proyecto puede solicitar que se vuelva a planificar
la fase actual (y, si es necesario, el proyecto).

Dirección de un Proyecto

Solicitud de aprobación
del Plan de Excepción

Solicitud de
aprobación del Plan
de la Fase siguiente Solicitud de un
Plan de Excepción

Actualizar el Producir un
Informar el final de fase Business Case Plan de Excepción

Actualizar el
Plan de Proyecto

Planificar la
fase siguiente

Gestión de los Límites de Fase

Se acerca el
límite de fase

Inicio de Control
un Proyecto de una Fase

Figura 17.1 Visión general de la Gestión de los Límites de Fase

214 | Gestión de los Límites de Fase
El resultado de la replanificación es un Plan de
Excepción que se somete a la aprobación de la
Junta de Proyecto del mismo modo que un Plan de
la Fase se somete a aprobación.
17.2 OBJETIVO
El objetivo del proceso de la Gestión de los Límites
de Fase es:
■■ Garantizar a la Junta de Proyecto que se hayan
completado y aprobado todos los productos del
Plan de la Fase actual
■■ Preparar el Plan de la Fase siguiente
■■ Revisar y, si es necesario, actualizar la
Documentación de Inicio del Proyecto
(concretamente, el Business Case, el Plan
de Proyecto, el enfoque del proyecto, las
estrategias, la estructura del equipo de gestión
del proyecto y las descripciones de los roles)
■■ Proporcionar la información que la Junta de
Proyecto necesita para evaluar la viabilidad
continua del proyecto, incluyendo la exposición
al riesgo agregada
■■ Registrar cualquier información o lecciones que
puedan ser de ayuda en fases posteriores de
este proyecto y/o en otros proyectos
■■ Solicitar la autorización para iniciar la fase
siguiente.
En el caso de las excepciones, los objetivos del
proceso de la Gestión de los Límites de Fase son:
■■ Preparar un Plan de Excepción siguiendo las
indicaciones de la Junta de Proyecto
■■ Solicitar la aprobación para reemplazar el Plan
de Proyecto o el Plan de la Fase actual con el
Plan de Excepción.
El proceso de la Gestión de los Límites de Fase
no se utiliza cuando se aproxima el fin de la fase
final (salvo que sea necesario elaborar un Plan
de Excepción), porque las actividades de revisión
del rendimiento de la fase final se incluyen en las
actividades de revisión del rendimiento de todo el
proyecto, como parte del proceso del Cierre de un
Proyecto.
17.3 Contexto
El proceso de la Gestión de los Límites de Fase se
basa en la división del proyecto en fases de gestión
(véase el Capítulo 10).
Un proyecto, tanto si es grande como pequeño,
necesita garantizar que los productos que se crean
proporcionarán los beneficios esperados, ya sea por
sí mismos o como parte de un programa mayor. Al
final de cada fase se debe confirmar si el enfoque
del proyecto sigue siendo correcto. Si es necesario,
se puede dar una nueva dirección al proyecto o
pararlo, para evitar desperdiciar tiempo y dinero.
También es importante reconocer que los proyectos
pueden funcionar mal o pueden verse afectados
por factores externos que invaliden su justificación
comercial. El pronóstico por parte del Project
Manager de que es probable que se supere alguna
de las tolerancias del proyecto o de una fase es un
indicador de preaviso de un posible fracaso. En esos
casos, es importante que exista un mecanismo de
rectificación para volver a encauzar el proyecto.
Una decisión firme de no seguir adelante no es un
fracaso. Sin embargo, proporcionar información
insuficiente de modo que la Junta de Proyecto no
pueda tomar una decisión bien informada es un
fracaso, porque puede conducir a una decisión
equivocada.
El proceso de la Gestión de los Límites de Fase
proporciona un medio para la implementación del
proceso de excepción.
17.4 Actividades
Las actividades del proceso de la Gestión de los
Límites de Fase están orientadas al Project Manager
e incluyen:
■■ Planificar la fase siguiente
■■ Actualizar el Plan de Proyecto
■■ Actualizar el Business Case
■■ Informar sobre el final de fase
■■ Elaborar un Plan de Excepción.
17.4.1 Planificar la fase siguiente
El Plan de la Fase siguiente se elabora cuando el
final de la fase de gestión en curso es inminente. El
cierre de actividades se debe planificar como parte
del Plan de la Fase final.
 Gestión de los Límites de Fase | 215

La planificación no es una actividad que se realice ●● Cualquier cambio en el equipo de gestión

de forma aislada. El Project Manager tendrá que
consultar a la Junta de Proyecto, la Garantía del
Proyecto, los Team Managers y, si es necesario,
otras partes interesadas, para elaborar un plan
viable. Cuantas más personas participen en la
planificación, más sólido será el plan (siempre que
quienes participen sean las personas adecuadas).
Véase el Capítulo 7 para más información sobre
planificación.
La Figura 17.2 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar los componentes de la Documentación
de Inicio del Proyecto. Podría ser necesario
consultar a la Junta de Proyecto sobre posibles
cambios que se tengan que llevar a cabo. Se
deberá revisar y, si es necesario, actualizar lo
siguiente:
●● Cualquier cambio en las expectativas de
calidad del cliente, los criterios de aceptación
o el enfoque del proyecto
●● Si las estrategias y controles son pertinentes
y apropiados
del proyecto o en sus descripciones de los
roles (en particular, la situación relativa a
los proveedores o recursos externos, ya que
éstos pueden afectar al Plan de la Fase)
■■ Preparar el Plan de la Fase siguiente:
●● Decidir sobre la mejor manera de presentar
el plan teniendo en cuenta sus destinatarios
y la forma en que se utilizará
●● Revisar el Plan de Proyecto para comprender
los productos necesarios para la fase
siguiente
●● Consultar en la Estrategia de Gestión de
la Calidad las normas y procedimientos de
calidad necesarios
●● Crear (o actualizar) la estructura jerárquica
de productos, las Descripciones de Productos
y el diagrama de flujo de los productos para
los productos que se deben entregar en la
siguiente fase
●● Revisar el Registro de Cuestiones, que
podría incluir cuestiones señaladas para su
evaluación al final de la fase o información
que afecte a la fase siguiente
●● Revisar en el Registro de Riesgos si existen
riesgos que puedan afectar al Plan de la

Actualizar Documentación de
Se acerca el Planificar la fase siguiente Inicio del Proyecto
límite de fase

Documentación de Crear Plan de la Fase

Inicio del Proyecto (fase siguiente)

Crear Descripciones de
Registro de Cuestiones Productos
(fase siguiente)

Registro de Riesgos Actualizar Fichas de Elementos

de Configuración

Archivo sobre las Actualizar

Lecciones Registro de Riesgos

Actualizar
Registro de Cuestiones

Actualizar
Registro de Calidad

Figura 17.2 Resumen de actividades para planificar la fase siguiente

216 | Gestión de los Límites de Fase

Fase siguiente y comprobar el estado de las
respuestas al riesgo mediante consultas a los
propietarios del riesgo
■■ Crear (o actualizar) las Fichas de Elementos de
ConFiguración para los productos que se deban
crear en la fase siguiente
■■ Actualizar el Registro de Cuestiones y el
Registro de Riesgos si se han identificado
nuevas cuestiones o riesgos (o si se necesita
modificar los que ya existen)
■■ Actualizar el Registro de Calidad en lo relativo
a las actividades de gestión de la calidad
planificadas. Esto debería incluir la revisión
de metas y las fechas de aprobación de los
productos.
La Tabla 17.1 muestra las responsabilidades para
esta actividad.
17.4.2 Actualizar el Plan de Proyecto
La Junta de Proyecto utiliza el Plan de Proyecto
durante todo el proyecto para evaluar el progreso.
El Plan de Proyecto se actualiza para reflejar el
progreso real de la fase que está finalizando y para
incluir la duración y costes previstos del Plan de
Excepción o el Plan de la Fase que está a punto de
comenzar.
Se utilizan los datos de fechas de finalización y
costes revisados cuando se actualiza el Business
Case.
Véase el Capítulo 7 para más información sobre
planificación.
La Figura 17.3 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Comprobar que el Plan de la Fase actual esté
actualizado con información sobre el progreso
real, y actualizarlo si es necesario
■■ Revisar el Plan de Proyecto para que refleje:
●● Datos de la situación real relativos al Plan de
la Fase en curso
●● Pronósticos del Plan de la Fase siguiente o
del impacto del Plan de Excepción
●● Cualquier cambio en la Descripción del
Producto del Proyecto
●● Las consecuencias de cualquier cuestión o
riesgo
●● Cualquier nuevo requisito o modificación de
requisitos de adaptación de los procesos de
PRINCE2 para el proyecto

Tabla 17.1 Responsabilidades para planificar la fase siguiente

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Documentación de Inicio del Proyecto Actualizar (R) (A) (A) (A) P R A.6

Plan de la Fase Crear (A) (A) (A) P R A.22

Fichas de Elementos de Configuración Crear/actualizar P R R A.12

Registro de Riesgos Actualizar P R A.26

Registro de Cuestiones Actualizar P R A.25

Registro de Calidad Actualizar R R P A.24

 Gestión de los Límites de Fase | 217

(Parte de la)
Actualizar el Documentación de
Plan de la Fase
(fase en curso) Plan de Proyecto Inicio del Proyecto

Actualizar Plan de Proyecto

Plan de la Fase
(fase siguiente)

Actualizar Registro de Cuestiones

Documentación de
Inicio del Proyecto

Actualizar Registro de Riesgos

Plan de Excepción

Figura 17.3 Resumen de actividades para actualizar el Plan de Proyecto

Cualquier producto adicional o modificado

●●
autorizado por la Junta de Proyecto
●● Cualquier cambio en la Documentación
de Inicio del Proyecto (por ejemplo,
modificaciones en el enfoque del proyecto,
las estrategias, los controles del proyecto,
la estructura del equipo de gestión del
proyecto o las descripciones de los roles)
■■ Actualizar el Registro de Cuestiones y el
Registro de Riesgos si se han identificado
nuevas cuestiones o riesgos (o si se necesita
modificar los ya existentes).
La Tabla 17.2 muestra las responsabilidades para
esta actividad.
Tabla 17.2 Responsabilidades para actualizar el Plan de Proyecto
17.4.3 Actualizar el Business Case
Uno de los principios de PRINCE2 es que los
proyectos deben tener una justificación comercial
continua.
Normalmente la Junta de Proyecto sólo está
autorizada a seguir adelante mientras el proyecto
se mantenga viable (es decir, cuando se prevea
obtener los beneficios dentro de los parámetros de
coste, tiempo, calidad, alcance y riesgo establecidos
en el Business Case acordado y vigente en ese
momento).
Sin embargo, los proyectos no se desarrollan en un
entorno estático. La realidad externa al proyecto

Productor – responsable de la producción del producto

Descripción de Producto disponible
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Plan de Proyecto Actualizar (A) (A) (A) P R A.22

Registro de Cuestiones Actualizar P R A.25

Registro de Riesgos Actualizar P R A.26

218 | Gestión de los Límites de Fase
cambia, al igual que la naturaleza y los tiempos
de elaboración de los productos del proyecto. El
Business Case debe reflejar estos cambios y debe
revisarse y modificarse para que siga siendo útil al
proyecto.
Como el Ejecutivo es responsable del Business Case,
el Project Manager debe consultar al Ejecutivo a la
hora de revisar y actualizar el Business Case de cara
a la aprobación por parte de la Junta de Proyecto.
Para más información sobre la justificación
comercial, véase el Capítulo 4.
La Figura 17.4 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Comprobar si se han producido cambios en
la propensión al riesgo y en la capacidad de
riesgo de las organizaciones participantes y
si se necesita volver a definir las tolerancias
de riesgo. Evaluar los riesgos del proyecto
utilizando el Registro de Riesgos para
determinar la exposición al riesgo agregada
del proyecto e identificar los principales
riesgos actuales que afecten al Business Case.
Esto debería incluir la verificación de que la
exposición al riesgo agregada se mantiene
dentro de las tolerancias de riesgo
■■ Actualizar el Plan de Revisión de Beneficios con
los resultados de las revisiones de beneficios si
se ha realizado alguna durante la fase
■■ Examinar y revisar:
●● El Plan de Revisión de Beneficios, para ver
los resultados de las revisiones de beneficios
Registro de Riesgos Actualizar el
Business Case
Registro de Cuestiones
(Parte de la)
Documentación de
Inicio del Proyecto
Plan de Proyecto
Plan de Revisión
de Beneficios
Figura 17.4 Resumen de actividades para actualizar el Business Case
realizadas durante la fase, en comparación
con los resultados esperados
●● El impacto de los cambios aprobados, ya
que éstos pueden afectar a los beneficios
previstos
●● El perfil de riesgo del proyecto y los riesgos
principales
●● El Registro de Cuestiones, para aquellas
cuestiones que puedan afectar al Business
Case
●● El Plan de Proyecto, para ver si la fecha
final de implementación del proyecto ha
cambiado, para mejor o para peor, lo cual
podría afectar a todos o algunos de los
beneficios esperados
●● El Plan de Proyecto, para ver si el coste de
entregar los productos del proyecto ha
cambiado, lo cual podría afectar al análisis
de costes y beneficios
●● El entorno de la empresa o del programa
en el que se entregarán los productos del
proyecto, ya que podría haber cambiado
●● Si se necesita realizar alguna revisión de
beneficios en la siguiente fase de gestión
■■ Revisar el Business Case y, si es necesario, el
Plan de Revisión de Beneficios, listos para la
aprobación por parte de la Junta de Proyecto
■■ Actualizar el Registro de Riesgos y el Registro
de Cuestiones si es necesario.
La Tabla 17.3 muestra las responsabilidades para
esta actividad.
(Parte de la)
Documentación de
Inicio del Proyecto
Actualizar
Business Case
Actualizar Plan de
Revisión de Beneficios
Actualizar
Registro de Riesgos
Actualizar
Registro de Cuestiones

Tabla 17.3 Responsabilidades para actualizar el Business Case
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Business Case Actualizar
Plan de Revisión de Beneficios Actualizar
Registro de Riesgos Actualizar
Registro de Cuestiones Actualizar
17.4.4 Informar sobre el final de fase
Debe informarse sobre los resultados de cada fase
a la Junta de Proyecto, para que el equipo de
gestión del proyecto pueda apreciar claramente el
progreso.
El Project Manager expresa su opinión sobre la
capacidad del proyecto de seguir cumpliendo con
el Plan de Proyecto y el Business Case, y evalúa la
situación general en lo relativo a los riesgos.
Esta actividad debe tener lugar tan cerca del final
de la fase como sea posible.
La Figura 17.5 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ En el caso de un Plan de Excepción:
Dependiendo del momento de la fase
●●
en el que surgió la excepción, podría ser
apropiado elaborar un Informe al Final de
Fase para informar sobre las actividades
realizadas hasta la fecha. Será la Junta
de Proyecto, en respuesta al Informe de
Excepción, quien determine si es necesario
hacerlo. Si es necesario un Informe al Final
de Fase, deben seguirse las indicaciones
para el Plan de la Fase que se describen a
continuación
■■ En el caso de un Plan de la Fase:
Gestión de los Límites de Fase | 219
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(R) (A) (A) (A) P R A.3
(R) (A) (A) (A) P R A.23
P R A.26
P R A.25
●● Revisar el estado del Business Case
actualizado y, en concreto, la obtención
de los beneficios esperados para la fase.
Confirmar que se hayan completado
las actividades del Plan de Revisión de
Beneficios para la fase actual
●● Revisar el Plan de la Fase para asegurar que
se hayan logrado los objetivos de la fase y
el Plan de Proyecto para asegurar que los
objetivos del proyecto sigan siendo viables
●● Revisar el rendimiento del equipo en la fase
●● Revisar el rendimiento de los productos en la
fase remitiéndose al Informe sobre el Estado
de los Productos (proporcionado por el
Apoyo al Proyecto)
●● Revisar las actividades de gestión de la
calidad de la fase y sus resultados
●● Asegurarse de que todos los productos
identificados en el Plan de la Fase actual
hayan sido completados y aprobados o se
hayan transferido a la siguiente fase
●● En el caso de entrega a cliente fase por
fase, confirmar la aceptación del usuario
y la aceptación de uso y mantenimiento
de aquellos productos cuya propiedad se
haya transferido al cliente. Identificar las
acciones a realizar recomendadas para los
productos entregados
220 | Gestión de los Límites de Fase

(Parte de la) Crear Informe al Final de Fase

Documentación de Informar final de fase (fase en curso)
Inicio del Proyecto

Crear Informe sobre

Business Case las Lecciones

Crear Acciones a realizar

Estrategia de Gestión
recomendadas
de la Comunicación

Solicitud de
aprobación del Plan
Plan de de la Fase siguiente
Revisión de Beneficios
Solicitud de
aprobación del Plan
de Excepción
Registro de
Cuestiones

Registro de
Riesgos

Registro de
Calidad

Plan de la Fase
(fase en curso)

Informe sobre el
Estado de los Productos

Archivo sobre las

Lecciones

Figura 17.5 Resumen de actividades para informar sobre el final de fase

Revisar las cuestiones planteadas, los

●● Fase (y, si procede, el Plan de Proyecto revisado,
riesgos que hayan surgido durante la fase el Plan de Revisión de Beneficios revisado y el
y cualquier respuesta al riesgo que se Business Case revisado [véase el Capítulo 13])
haya adoptado. Incluir información sobre ■■ Revisar la Estrategia de Gestión de la
la exposición al riesgo agregada actual Comunicación para ver si se deben enviar en
●● Elaborar un Informe al Final de Fase para este momento copias del Informe al Final
la fase actual de Fase (y, si procede, del Informe sobre las
■■ Podría ser apropiado elaborar en este Lecciones) a las partes interesadas externas.
momento un Informe sobre las Lecciones, La Tabla 17.4 muestra las responsabilidades para
especialmente en el caso de proyectos largos esta actividad.
en los que la revisión provisional de lecciones
o el propio proyecto pueden ser de utilidad
para la gerencia de la empresa o del programa.
Consultar el Archivo sobre las Lecciones para
identificar lecciones sobre las que sea apropiado
informar
■■ Solicitar la aprobación por parte de la Junta de
Proyecto del Plan de Excepción o el Plan de la

Tabla 17.4 Responsabilidades para informar sobre el final de fase
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto
Informe al Final de Fase
Informe sobre las Lecciones
Acciones a realizar recomendadas
17.4.5 Elaborar un Plan de Excepción
Si se prevé que la fase o el proyecto va a
exceder los límites de tolerancia acordados,
automáticamente deja de contar con la aprobación
de la Junta de Proyecto.
Los Planes de Excepción son solicitados por la
Junta de Proyecto como respuesta a un Informe
de Excepción. Aunque se elaborará un Plan de
Excepción antes del límite de fase planificado,
su aprobación por parte de la Junta de Proyecto
marca un límite de fase para la fase revisada.
La planificación no es una actividad que se realice
de forma aislada. El Project Manager tendrá que
consultar a los miembros de la Junta de Proyecto,
a la Garantía del Proyecto, a los Team Managers
y, si es necesario, a otras partes interesadas, para
elaborar un plan viable. Cuantas más personas
participen en la planificación, más sólido será el
plan. Véase el Capítulo 7 para más información
sobre planificación.
La Figura 17.6 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Actualizar el Registro de Cuestiones (y, si es
necesario, el Informe de Cuestiones), para
reflejar la solicitud por parte de la Junta
de Proyecto de que se elabore un Plan de
Excepción
Gestión de los Límites de Fase | 221
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
Acción
Crear (A) (A) (A) P R A.13
Crear (A) (A) (A) P R A.20
Crear (A) (A) (A) P R
■■ Revisar y, si es necesario, actualizar la
Documentación de Inicio del Proyecto. Podría
ser necesario consultar a la Junta de Proyecto
sobre posibles cambios que se tengan que llevar
a cabo. Se deberá revisar lo siguiente:
●● Si las expectativas de calidad del cliente
permanecen sin cambios
●● Que el enfoque del proyecto, las estrategias
y los controles son pertinentes y apropiados
●● Cualquier cambio en el equipo de gestión
del proyecto o en sus descripciones de los
roles (en particular, la situación relativa a los
proveedores o recursos externos, ya que ésta
puede afectar al Plan de Excepción)
■■ Elaborar el Plan de Excepción:
●● Examinar el Plan de la Fase para definir los
productos necesarios para la fase
●● Examinar el Informe de Excepción para
obtener información (como las acciones
recomendadas) que contribuirá al Plan de
Excepción
●● Si el Plan de Excepción requiere que se creen
nuevos productos, examinar la Estrategia de
Gestión de la Calidad para comprobar las
normas y procedimientos necesarios
●● Actualizar la estructura jerárquica de
productos, las Descripciones de Productos
y el diagrama de flujo de los productos
para los productos que se deben entregar
conforme al Plan de Excepción
222 | Gestión de los Límites de Fase

Solicitud de Producir un Actualizar Registro de Cuestiones

Plan de Excepción Plan de Excepción

Plan de la Fase
(fase en curso) Actualizar Documentación de
Inicio del Proyecto

Informe de Excepción Crear

Plan de Excepción

Registro de Cuestiones Crear Descripción(es)

de Producto(s)

Registro de Riesgos Actualizar Fichas de Elementos

de Configuración

Documentación de
Actualizar
Inicio del Proyecto Registro de Calidad

Actualizar
Registro de Riesgos

Figura 17.6 Resumen de actividades para elaborar un Plan de Excepción

Actualizar el Registro de Calidad en lo

●●
relativo a las actividades de gestión de la
calidad planificadas
■■ Crear (o actualizar) las Fichas de Elementos de
ConFiguración para los productos que se deban
crear conforme al Plan de Excepción
■■ Actualizar el Registro de Cuestiones y el
Registro de Riesgos si se han identificado
nuevas cuestiones o riesgos (o si se necesita
modificar los ya existentes)
■■ Actualizar el Registro de Calidad en lo relativo
a las actividades de gestión de la calidad
planificadas. Esto debería incluir la revisión
de metas y las fechas de aprobación de los
productos.
La Tabla 17.5 muestra las responsabilidades para
esta actividad.
 Gestión de los Límites de Fase | 223

Tabla 17.5 Responsabilidades para elaborar un Plan de Excepción

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Documentación de Inicio del Proyecto Actualizar (R) (A) (A) (A) P R A.6

Plan de Excepción Crear (A) (A) (A) P R A.22

Fichas de Elementos de Configuración Crear/actualizar R R P A.12

Registro de Riesgos Actualizar P R A.26

Registro de Cuestiones Actualizar P R A.25

Registro de Calidad Actualizar R (R) R P A.24

 18
Cierre de un Proyecto
18 Cierre de un Proyecto

18.1 Propósito ■■ Asegurarse de que la sede puedea prestar

asistencia respecto de los productos cuando se
El propósito del proceso del Cierre de un
disuelva el proyecto
Proyecto es proporcionar un punto fijo en el
■■ Revisar el rendimiento del proyecto tomando
que se confirme la aceptación del producto del
como referencia sus versiones baseline
proyecto, y reconocer que se han alcanzado los
■■ Evaluar todos los beneficios ya materializados,
objetivos establecidos en la Documentación de
Inicio del Proyecto (o se han alcanzado los cambios actualizar las previsiones de los beneficios
aprobados respecto de los objetivos), o que el restantes y planificar la revisión de aquellos
proyecto no tiene nada más que ofrecer. beneficios sin materializar
■■ Garantizar que se ha hecho lo necesario para
dar respuesta a todas las cuestiones y riesgos
18.2 Objetivo pendientes mediante acciones a realizar
Los objetivos del proceso del Cierre de un Proyecto recomendadas.
son:
■■ Verificar la aceptación por el usuario de los
productos del proyecto

Dirección de un Proyecto

Cierre
prematuro

Control Se acerca el Preparar el Preparar el

cierre prematuro
final del proyecto cierre planificado
de una Fase

Entregar
productos

Cierre de
un Proyecto Evaluar el proyecto

Recomendar el Recomendación
cierre del proyecto de cierre

Figura 18.1 Visión general del proceso del Cierre de un Proyecto

228 | Cierre de un Proyecto
18.3 Contexto
Una de las características más importantes de un
proyecto PRINCE2 es que es finito, es decir, cuenta
con un principio y un final. Si el proyecto perdiese
este rasgo distintivo, también perdería algunas de
sus ventajas respecto al enfoque de una gestión
puramente operativa.
Un final claro del proyecto:
■■ Tendrá siempre más éxito que una transición
borrosa y no controlada a la vida operativa,
puesto que constituye un reconocimiento por
todas las partes interesadas de que:
●● Se han cumplido los objetivos originales (en
el respeto de cualquier cambio aprobado)
●● El proyecto actual ha llegado a su fin
●● O bien los productos de este proyecto se
convierten en operativos o se transforman
en aportaciones a proyectos futuros o
programas más amplios
●● El equipo de gestión de proyecto puede
disolverse
●● Ya no se debería incurrir en más costes a
imputar al proyecto
■■ Proporciona la oportunidad de asegurarse de
que se hayan identificado todas las metas y
objetivos no alcanzados para poder abordarlos
en el futuro
■■ Transfiere la propiedad de los productos al
cliente y extingue la responsabilidad del equipo
de gestión del proyecto.
Las actividades de cierre deberían planificarse
como parte del Plan de Fase para la fase de gestión
final. Al cerrar un proyecto, se requiere un trabajo
adicional de preparación de información para la
Junta de Proyecto a fin de obtener su autorización
para cerrar el proyecto. Posteriormente el Ejecutivo
debería también notificar a la gerencia corporativa
o del programa que se ha cerrado el proyecto
(véase el Capítulo 13).
También es posible que la Junta de Proyecto
desee activar el cierre prematuro del proyecto si
se dan ciertas circunstancias (por ejemplo, si el
Business Case ha dejado de ser válido). Aunque se
disponga el cierre prematuro del proyecto, habrá
que completar igualmente este proceso, el cual
podría tener que adaptarse a la situación real del
proyecto.
Puede que sea necesario realizar un cierto número
de acciones específicas para los productos del
proyecto una vez finalizado el proyecto y éstas
deben documentarse y planificarse en forma de
acciones a realizar recomendadas. Éstas pueden
estar dirigidas a diferentes personas y por tanto
puede que tengan que recomendarse de forma
individual. El formato y el contenido dependerán
de las necesidades del receptor: algunos querrán
un informe formal, otros una anotación en el
archivo de un sistema y otros una reunión.
18.4 Actividades
Las actividades del Cierre de un Proyecto están
orientadas al Project Manager e incluyen:
■■ Preparar el cierre planificado
■■ Preparar el cierre prematuro
■■ Entregar los productos
■■ Evaluar el proyecto
■■ Recomendar el cierre del proyecto.
18.4.1 Preparar el cierre planificado
Antes de que pueda recomendarse el cierre del
proyecto, el Project Manager debe asegurarse
de que se han obtenido y entregado todos los
resultados esperados.
La Figura 18.2 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Actualizar el Plan de Proyecto con información
real sobre la fase final
■■ Solicitar un Informe sobre el Estado de los
Productos al Apoyo al Proyecto. A partir del
Informe sobre el Estado de los Productos,
garantizar que los productos del proyecto:
●● Han sido aprobados por las autoridades
especificadas en sus Descripciones de
Productos
●● Cumplen con todos los criterios de calidad o
están cubiertos por concesiones aprobadas
■■ Confirmar que el proyecto ha cumplido con
lo establecido en la Descripción del Producto
del Proyecto y se han cumplido los criterios de
aceptación
■■ Solicitar aprobación para notificar a la gestión
corporativa o del programa que ya pueden
liberarse los recursos (o están a punto de
liberarse).
La Tabla 18.1 muestra las responsabilidades para
esta actividad.
 Cierre de un Proyecto | 229

Se acerca el Preparar el cierre Documentación de

final del proyecto planificado Inicio del Proyecto

Informe sobre el
Actualizar
Estado de los Productos Plan de Proyecto

Documentación de
Inicio del Proyecto

Plan de Proyecto

Figura 18.2 Resumen de actividades para preparar el cierre planificado

Tabla 18.1 Responsabilidades para preparar el cierre planificado

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Plan de Proyecto Actualizar P R A.22

Informe sobre el Estado de los Productos Crear R R P A.19

18.4.2 Preparar el cierre prematuro PRINCE2 recomienda las siguientes acciones:

En algunas situaciones, es posible que la Junta
de Proyecto haya solicitado al Project Manager
el cierre prematuro del proyecto. En dichas
circunstancias, el Project Manager debe asegurarse
de que el trabajo en curso simplemente no se
abandone sino que se rescate cualquier valor del
proyecto creado hasta la fecha y debe controlar
que cualquier falta de continuidad debido a
la cancelación del proyecto se comunique a la
gerencia corporativa o del programa.
La Figura 18.3 muestra los aportes y resultados
relativos a esta actividad.
■■ Actualizar el Registro de Cuestiones (y el
Informe de Cuestiones si es necesario) para
dejar constancia de la solicitud de cierre
prematuro
■■ Actualizar el Plan de Proyecto con información
real sobre la fase final
■■ Solicitar un Informe sobre el Estado de los
Productos al Apoyo al Proyecto. A partir de
esto, determinar qué productos del proyecto:
●● Han sido aprobados por las autoridades
especificadas en sus Descripciones de
Productos
230 | Cierre de un Proyecto

Cierre Preparar el cierre Actualizar

prematuro prematuro Registro de Cuestiones

Informe sobre el
Estado de los Productos Documentación de
Inicio del Proyecto

Documentación de
Inicio del Proyecto Actualizar
Plan de Proyecto

Plan de Proyecto Crear Estimaciones de

trabajo adicional

Figura 18.3 Resumen de actividades para preparar el cierre prematuro

Se encuentran en desarrollo actualmente (y

●●
cuáles de éstos tienen que ser finalizados)
●● Están cubiertos por concesiones aprobadas
●● Están aún por iniciarse
●● Se les tiene que dotar de seguridad
●● Pueden ser útiles para otros proyectos
■■ Acordar los medios para recuperar los
productos que se han completado o están en
desarrollo (si procede). Esta acción requerirá
consultas con la Junta de Proyecto, y puede
incluir trabajo adicional para crear, dotar de
seguridad o completar productos que puedan
ser útiles para otros proyectos (por ejemplo,
hacer que un edificio a medio construir sea
seguro y esté protegido contra la intemperie).
En algunos casos, el trabajo adicional puede
requerir un Plan de Excepción
■■ Solicitar aprobación para notificar a la gestión
corporativa o del programa de que pueden
liberarse los recursos antes de tiempo (o están a
punto de liberarse).
La Tabla 18.2 muestra las responsabilidades para
esta actividad

Tabla 18.2  Responsabilidades para preparar el cierre prematuro

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Registro de Cuestiones Actualizar P A.25

Plan de Proyecto Actualizar P R A.22

Informe sobre el Estado de los Productos Crear R R P A.19

Cálculos de trabajo adicional Crear (A) (A) (A) P R


18.4.3 Entregar los Productos
Los productos del proyecto deben trasladarse a un
entorno de uso y mantenimiento antes de que se
cierre el proyecto. Esto puede ocurrir como una
sola release al final del proyecto, o es posible que
el enfoque del proyecto incluya una entrega por
fases de modo que los productos se entreguen en
una serie de releases.
En el caso de un cierre prematuro, puede que
algunos productos hayan sido aprobados pero no
entregados aún y, en función de lo que recomiende
la Junta de Proyecto, es posible que la propiedad
de algunos o de todos esos productos tenga que
transferirse al cliente.
Cuando se entreguen los productos, es posible
que el Plan de Revisión de Beneficios tenga que
ser actualizado para incluir la(s) revisión(es) de
los beneficios del proyecto en relación con el
rendimiento de los productos en uso del proyecto.
Dichas revisiones de beneficios pueden identificar si
se han producido efectos colaterales (beneficiosos
o adversos) que puedan servir como lecciones útiles
para otros proyectos.
La revisión de beneficios post-proyecto no es una
actividad del proyecto, pero sí lo es planificar
la realización de dicha revisión de beneficios.
Cuando el proyecto sea parte de un programa,
las actividades de gestión de los beneficios
del programa se ocuparán de las revisiones de
beneficios post-proyecto.
La Figura 18.4 muestra los aportes y resultados
relativos a esta actividad.
Registro de Cuestiones
Entregar
productos
Registro de Riesgos
Documentación de
Inicio del Proyecto
Estrategia de Gestión
de la Configuración
Figura 18.4 Resumen de actividades para entregar los productos
Cierre de un Proyecto | 231
PRINCE2 recomienda las siguientes acciones:
■■ Mediante consultas con el equipo de gestión
del proyecto, preparar las acciones a realizar
recomendadas para los productos del proyecto
de modo que incluyan cualquier trabajo no
completado, cuestiones y riesgos. Podría
haber acciones a realizar recomendadas
específicas para cada producto o grupo de
usuarios independientes (por ejemplo, recursos
humanos, finanzas, operaciones, etc.)
■■ Comprobar que el Plan de Revisión de
Beneficios incluye las actividades post-proyecto
para confirmar que no pueden medirse los
beneficios hasta que los productos del proyecto
hayan sido utilizados durante un tiempo (por
ejemplo, requisitos de fiabilidad)
■■ Debe examinarse la Estrategia de Gestión
de la ConFiguración para confirmar cómo
se entregarán los productos a aquellos que
realizarán su mantenimiento durante su vida
útil:
●● Confirmar que se ha establecido el entorno
de uso y mantenimiento correcto
●● Se deben considerar las necesidades de
que se preste mantenimiento inicial a cada
producto que se entregue, puesto que la
etapa inicial de uso de un producto coincide
con el período de máxima demanda para la
organización que presta el mantenimiento
●● Cuando el producto requiera un alto nivel
de asistencia y mantenimiento que pueda
resultar muy costoso, el Project Manager
deberá asegurarse de que se ha preparado
(Parte del)
Informe al
Final de Proyecto
Crear Acciones a realizar
recomendadas
Actualizar Fichas de Elementos
de Configuración
Actualizar Plan de Revisión
de Beneficios
Obtener Testimonios
documentales
de aceptación
232 | Cierre de un Proyecto
un acuerdo o contrato de nivel de servicio
adecuado entre las organizaciones de uso
y mantenimiento y los usuarios finales. En
estos casos, el acuerdo de nivel de servicio
debe incluirse en forma de producto que
tiene que entregarse como parte del plan
●● Confirmar la aceptación por parte de las
organizaciones de uso y mantenimiento
●● Solicitar y obtener certificados de aceptación
(como testimonios documentales)
●● Transferir la responsabilidad de los productos
del proyecto a las organizaciones de uso
y mantenimiento y actualizar las Fichas
de Elementos de ConFiguración de los
productos.
La Tabla 18.3 muestra las responsabilidades para
esta actividad.
18.4.4 Evaluar el proyecto
Las organizaciones con éxito aprenden de sus
experiencias de gestionar proyectos. A la hora
de evaluar el proyecto, el objetivo es evaluar el
grado de éxito o fracaso del proyecto. También
podría ser posible mejorar las estimaciones para
futuros proyectos analizando las estimaciones y
comparándolas con las medidas del progreso real
de este proyecto.
Tabla 18.3 Responsabilidades para entregar los productos
Productor – responsable de la producción del producto
Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Producto Acción
Acciones a realizar recomendadas Crear/actualizar
Fichas de Elementos de Configuración Actualizar
Plan de Revisión de Beneficios Actualizar
Testimonio documental de aceptación Obtener
La Figura 18.5 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Revisar el propósito original del proyecto
acordado en la fase de inicio y definido en la
versión baseline de la Documentación de Inicio
del Proyecto disponible en esa fase
■■ Revisar los cambios aprobados tal y como se
definen en la versión actual de los componentes
de la Documentación de Inicio del Proyecto
■■ Mediante consultas con el equipo de gestión
del proyecto, preparar un Informe al Final de
Proyecto que incluya:
●● El resumen del Project Manager sobre el
rendimiento del proyecto
●● Una evaluación de los resultados del
proyecto tomando como referencia los
beneficios esperados incluidos en el Business
Case
●● Una revisión del rendimiento del proyecto
tomando como referencia sus metas y
tolerancias planificadas
●● Una revisión del rendimiento del equipo
●● Una revisión de los productos del proyecto
(que debe incluir un resumen de todas las
acciones a realizar recomendadas)
Descripción de Producto disponible
Corporativa/Programa
Garantía del Proyecto
Proveedor Principal
Apoyo al Proyecto
Project Manager
Usuario Principal
Team Manager
Ejecutivo
(A) (A) (A) P R
A R P A.12
(A) (R) (R) (R) P R A.23
(A) (A) (A) P R
 Cierre de un Proyecto | 233

Documentación de
Informe al
Inicio del Proyecto Evaluar el proyecto Final de Proyecto

(Parte del)
Informe al Crear Informe sobre
Final de Proyecto las Lecciones

Acciones a realizar
recomendadas

Registro de Cuestiones

Registro de Riesgos

Registro de Calidad

Archivo sobre las

Lecciones

Figura 18.5 Resumen de actividades para evaluar el proyecto

●●Si es necesario, las razones documentadas después de que los productos hubieran
de por qué el proyecto se cerró de forma pasado los controles de calidad) y estadísticas
prematura sobre cuestiones y riesgos
■■ Mediante consultas con el equipo de gestión ●● Todos los conocimientos útiles adquiridos en
del proyecto, preparar un Informe sobre las relación con la adaptación de PRINCE2 a un
Lecciones con las lecciones que puedan aplicarse entorno de proyecto específico.
a futuros proyectos y solicitar la aprobación de
La Tabla 18.4 muestra las responsabilidades para
la Junta de Proyecto para enviarlo a la gestión
esta actividad.
corporativa o del programa. El informe debe
incluir:
●● Una revisión de lo que salió bien, lo que
salió mal y cualquier recomendación a ser
considerada por la gerencia corporativa o
del programa; concretamente, el método
de gestión de proyectos, todos los métodos
especializados utilizados, estrategias y
controles del proyecto, y acontecimientos
anormales que causaron desviaciones
●● Una revisión de los cálculos útiles como:
cuánto esfuerzo fue necesario para crear
los productos, qué nivel de eficacia tuvo la
Estrategia de Gestión de la Calidad a la hora
de diseñar, desarrollar y completar productos
que desempeñen correctamente su función
(por ejemplo, cuántos errores se detectaron
234 | Cierre de un Proyecto

Tabla 18.4 Responsabilidades para evaluar el proyecto

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación

Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo
Producto Acción
Informe al Final de Proyecto Crear (A) (A) (A) P R A.14

Informe sobre las Lecciones Crear (A) (R) (R) (R) P R A.20

18.4.5 Recomendar el cierre del proyecto

Cuando el Project Manager haya confirmado que
puede cerrarse el proyecto, se deberá remitir una
recomendación de cierre a la Junta de Proyecto.
La Figura 18.6 muestra los aportes y resultados
relativos a esta actividad.
PRINCE2 recomienda las siguientes acciones:
■■ Utilizar la Estrategia de Gestión de la
Comunicación para identificar cualquier
organización o parte interesada que necesite
saber que se está cerrando el proyecto. Tener
en cuenta en este momento las actividades de
comunicación para las relaciones públicas y
oportunidades de marketing
■■ Cerrar el Registro de Cuestiones, el Registro de
Riesgos, el Registro de Calidad, el Archivo Diario
y el Archivo sobre las Lecciones del proyecto
■■ Toda la información del proyecto debe
archivarse en un lugar seguro (conforme a la
Estrategia de Gestión de la ConFiguración) para
que en el futuro pueda realizarse una auditoría
de las decisiones, las acciones y el rendimiento
del equipo de gestión del proyecto
■■ Preparar y remitir un borrador de notificación
de cierre de proyecto a la Junta de Proyecto
para su consideración, indicando que se ha
cerrado el proyecto.
La Tabla 18.5 muestra las responsabilidades para
esta actividad.
 Cierre de un Proyecto | 235

Documentación de Recomendar el Cerrar Registro de Cuestiones

Inicio del Proyecto cierre del proyecto

Estrategia de Gestión Cerrar

Registro de Riesgos
de la Comunicación

Cerrar
Registro de Calidad

Cerrar
Archivo Diario

Cerrar Archivo sobre las

Lecciones

Preparar Borrador de notificación

de cierre del proyecto

Recomendación
de cierre

Figura 18.6 Resumen de actividades para recomendar el cierre del proyecto

Tabla 18.5 Responsabilidades para recomendar el cierre del proyecto

Productor – responsable de la producción del producto

Descripción de Producto disponible

Revisor – idealmente, independiente de la producción
Aprobador – confirma la aprobación
Corporativa/Programa

Garantía del Proyecto

Proveedor Principal

Apoyo al Proyecto
Project Manager
Usuario Principal

Team Manager
Ejecutivo

Producto Acción
Registro de Cuestiones Cerrar P A.25

Registro de Riesgos Cerrar P A.26

Registro de Calidad Cerrar P A.24

Archivo Diario Cerrar P A.2

Archivo sobre las Lecciones Cerrar P A.1

Borrador de la notificación de cierre del proyecto Preparar (A) (A) (A) P R

 Adaptación de
PRINCE2 al
19
entorno del proyecto
19 Adaptación de PRINCE2 al entorno del
proyecto
19.1 ¿Qué es la adaptación?
PRINCE2 se puede utilizar cualquiera sea la escala,
complejidad, ubicación geográfica o cultura
del proyecto, tanto si es parte de un programa
como si se está gestionado como un proyecto
‘independiente’. De hecho, es un principio que un
proyecto PRINCE2 adapte el método para que sea
apropiado para cada contexto.
El concepto de adaptación se refiere al uso
apropiado de PRINCE2 en un cualquier proyecto
dado, asegurando que haya la cantidad
correcta de planificación, control, gobierno y
uso de los procesos y temáticas, mientras que
la implementación de PRINCE2 en toda una
organización se conoce como adopción. En la Tabla
19.1 se expone la diferencia entre adopción y
adaptación.
19.2 Enfoque general de la
adaptación
Algunos proyectos podrían afirmar que no
necesitan ‘todo PRINCE2’ y que por lo tanto sólo
han implementado parte del método. Esto quizás
revele una comprensión equivocada de PRINCE2
porque el método ha sido diseñado para ser
Tabla 19.1 Adopción y adaptación
Adopción
Hecha por la organización para implementar PRINCE2.
Se centra en:
■■ Responsabilidades definidas en los procesos
■■ Reglas de escala/orientación
(por ej., tarjeta de puntuación)
■■ Normas (plantillas, definiciones)
■■ Capacitación y desarrollo
■■ Integración con los procesos comerciales
■■ Herramientas
■■ Garantía de procesos.
Orientación en el modelo de madurez (Maturity Model)
de PRINCE2.
adaptado. La adaptación apropiada de PRINCE2
involucra, entonces, PRINCE2 completo.
La adaptación no consiste en omitir elementos
de PRINCE2. El método no es una serie de silos
aislados donde un elemento cualquiera se puede
omitir sin que afecte a los otros. PRINCE2 es una
red de elementos interrelacionados: las temáticas
se utilizan en los procesos; las técnicas se utilizan
para dar vida a las temáticas y las personas que
desempeñan roles en el proyecto crean productos
de gestión. Si un practitioner omite un elemento,
se debilita la gestión del proyecto para el proyecto.
Por lo tanto, la adaptación del método consiste en
tener en cuenta los factores externos (tales como
cualquier norma corporativa que es necesario
aplicar) y los factores del proyecto (tales como la
escala del proyecto) cuando se utilice PRINCE2.
La meta es aplicar un nivel de gestión que no
sobrecargue el proyecto pero que proporcione
un nivel de control apropiado dados los factores
externos y del proyecto.
El peligro de no adaptar PRINCE2 es que puede
llevar a una gestión ‘robótica’ del proyecto si se
sigue cada actividad del proceso y se produce cada
producto de gestión sin hacer preguntas. Ésta es
Adaptación
Hecha por el equipo de gestión del proyecto para adaptar
el método al contexto de un proyecto específico.
Se centra en:
■■ Adaptar las temáticas (mediante las estrategias y
controles)
■■ Incorporar términos / lenguaje específicos
■■ Revisar las Descripciones de Productos para los
productos de gestión
■■ Revisar las descripciones de los roles para los roles del
proyecto PRINCE2
■■ Ajustar los procesos de modo que correspondan a lo
anterior.
Orientación en este manual.
240 | Adaptación de PRINCE2 al entorno del proyecto

• Multiorganizativo
• Cliente/proveedor externo
• Normas corporativas
• Dentro de un programa
• Madurez de la organización (por ej., centro de excelencia)
• Términos y lenguaje • Escala
• Ubicación geográfica • Complejidad de la solución
• Cultura de la organización • Madurez del equipo
• Prioridad del proyecto • Tipo de proyecto y modelo de
• etc. ciclo de vida
• etc.

Factores Principios Factores

ambientales de PRINCE2 del proyecto

Adaptar

• Adaptar las temáticas (mediante las estrategias y los controles)

• Revisar los términos y el lenguaje
• Revisar las Descripciones de Productos para los productos de gestión
• Revisar las descripciones de los roles
• Ajustar los procesos de modo que correspondan a lo anterior
• Dejar constancia en la Documentación de Inicio del Proyecto

Figura 19.1 Influencias en la exigencia de adaptación

una trampa común en la gestión de proyectos 19.2.2 Adaptación de las temáticas

basada en plantillas.
Adaptación, por lo tanto, es pensar en la manera
en que el método se aplicará y luego utilizarlo
con delicadeza. La Figura 19.1 muestra la manera
en que se evalúan los factores del entorno y del
proyecto a fin de adaptar el método.
19.2.1 Aplicación de los principios
Debido a que los principios de PRINCE2 son
universales, siempre serán de aplicación y no se
adaptan. Al examinar los principios, el practitioner
puede comprender cómo adaptar la temática a los
factores del entorno y del proyecto sin que pierda
su valor.
Adaptar una temática no necesariamente significa
modificar el método. En la mayoría de los casos, los
factores del entorno y del proyecto se incorporan
a las estrategias y a los controles del proyecto. Las
políticas y normas corporativas o del programa
pertinentes se registran y se documentan en la
Estrategia de Gestión del Riesgo, la Estrategia de
Gestión de la Calidad, la Estrategia de Gestión
de la Configuración y la Estrategia de Gestión de
la Comunicación del proyecto. Estos productos
de gestión describirán los procedimientos a
ser utilizados en el proyecto que cumplen los
requerimientos de la organización corporativa o
del programa. El nivel de control requerido influirá
en la formalidad y la frecuencia del seguimiento, la
revisión y la presentación de informes.
 Adaptación de PRINCE2 al entorno del proyecto | 241
19.2.3 Aplicación de los términos y el
lenguaje de la organización
Quizás sea necesario adaptar el método para
incorporar los términos y el lenguaje de la
organización corporativa o del programa. Por
ejemplo, si la organización corporativa o del
programa utiliza el término Caso de Inversión más
bien que ‘Business Case’, podría ser apropiado
sustituir el término en toda la documentación del
proyecto si ello mejora la comprensión.
19.2.4 Adaptación de los productos de
gestión
PRINCE2 facilita contenidos básicos de las
Descripciones de Productos para aquellos productos
de gestión que requieren un propósito o una
composición particulares para ser utilizados por
las temáticas y los procesos. Al adaptar PRINCE2,
se podrían adaptar los productos de gestión,
en cuyo caso podría ser necesario modificar sus
Descripciones de Productos o proporcionar una
plantilla para éstos. Todos los que participan en
el proyecto deben tener claridad sobre cuál es
el propósito del producto de gestión, qué debe
abarcar y cuáles son los criterios de calidad. Por
ejemplo, en un entorno comercial, quizás sea
necesario que el Paquete de Trabajo incluya
detalles de la orden de compra y los términos y
condiciones adjuntos.
19.2.5 Adaptación de los roles
Es necesario considerar cuidadosamente la
estructura organizativa de PRINCE2 para todos
los proyectos. En el Apéndice C se proporcionan
resúmenes modelo de las descripciones de los
roles, pero se prevé que será necesario adaptar
éstas de modo que correspondan a la capacidad y
autoridad reales de las personas en el contexto del
rol que se les asignará en el proyecto. Por ejemplo,
para un proyecto en un entorno de programa, la
responsabilidad del Plan de Revisión de Beneficios
podría recaer sobre el programa. Si ese fuera el
caso, esta responsabilidad se debería borrar de la
descripción del rol del Ejecutivo.
19.2.6 Adaptación de los procesos
Es necesario realizar todas las actividades de los
procesos de PRINCE2. El elemento variable es
que las responsabilidades de la ejecución de las
actividades podrían cambiar (si cualquier rol se ha
adaptado) y quizás sea necesario cambiar cualquier
referencia a los productos de gestión (si se ha
adaptado cualquier producto de gestión).
19.3 Ejemplos de adaptación de
PRINCE2
En las secciones 19.4 a 19.10 se proporcionan
algunos ejemplos de la manera en que PRINCE2 se
puede adaptar.
Los ejemplos cubren algunos de los factores del
entorno y del proyecto a los que muchos proyectos
se enfrentan:
■■ Proyectos en un entorno de programa
■■ Escala del proyecto
■■ Entorno de cliente/proveedor comercial
■■ Proyectos multi-organizativos
■■ Tipo de proyecto
■■ Diferencias sectoriales
■■ Cuerpos de Conocimientos sobre gestión de
proyectos.
Los factores de entorno y del proyecto que se
muestran no son una lista exhaustiva ya que la
aplicación de PRINCE2 no tiene límites. Sólo se
proporciona orientación general para ilustrar
las consideraciones a tener en cuenta y algunas
tácticas que se pueden aplicar. La orientación no se
debe interpretar como el enfoque definitivo a la
adaptación ya que no es específica a un proyecto
determinado. El practitioner debe considerar las
ventajas y desventajas de las elecciones en materia
de adaptación en función de su relación con el
contexto específico del proyecto.
Para una organización que ha adoptado PRINCE2,
la versión adoptada del método todavía requiere
adaptación.
242 | Adaptación de PRINCE2 al entorno del proyecto
Proyectos
Basados en los productos a entregar
Finitos – inicio y fin definidos
Productos a entregar según
alcance y límites definidos
Entrega de productos
Beneficios generalmente logrados
después del cierre del proyecto
Escala de tiempo más corta
Figura 19.2 Comparación entre proyectos y programas
19.4 Proyectos en un entorno de
programa
Un programa es una estructura organizativa
temporal flexible creada para coordinar, dirigir
y controlar la implementación de un conjunto
de proyectos y actividades relacionados a fin
de entregar resultados finales y beneficios
relacionados con los objetivos estratégicos de
la organización. Un programa puede tener una
duración de varios años.
La distinción entre proyectos y programas es que
los proyectos generalmente producen o cambian
algo y luego se disuelven. Es probable que los
beneficios de la tarea se concreten después de que
se haya completado el proyecto. Los programas
generalmente se utilizan para ayudar a transformar
a las organizaciones. Por lo tanto, la organización
temporal que constituye un programa tiende a
tener una vida que cubre la realización de los
beneficios – lo cual podría implicar varios años.
Esto se ilustra en la Figura 19.2.
Los proyectos que operan en un entorno de
programa se benefician de una serie de ventajas
y hay diversas maneras en que PRINCE2 se puede
adaptar para su uso dentro de un programa.
Programas
Basados en una visión de “estado final”
Sin un camino previamente definido
Cambios en la capacidad comercial
Entrega coordinada de resultados –
incluye proyectos que no entregan
beneficios directamente
Beneficios logrados durante
el programa y después
Escala de tiempo más larga
En las secciones que figuran a continuación se
explica la manera en que PRINCE2 se puede
adaptar al trabajar en un entorno de programa
(utilizando el marco Managing Successful
Programmes de OGC) al estudiar la manera de
adaptar las temáticas, los procesos y los productos
de gestión.
19.4.1 Temáticas
19.4.1.1 Business Case
El programa definirá las normas que el proyecto
necesitará utilizar al desarrollar el Business Case.
El Business Case del proyecto se añadirá al Business
Case general del programa y es probable que
su contenido se reduzca. Quizás sólo incluya los
detalles del presupuesto, una lista de beneficios
(y la tolerancia de beneficios) así como una
afirmación sobre la manera en que el proyecto
está contribuyendo al plan maestro del programa,
con los aspectos de justificación del Business Case
para el proyecto incluidos en el Business Case del
programa.
En algunos casos, el programa podría producir y
mantener el Business Case y aun existir en detalle
antes de que se inicie el proyecto.
 Adaptación de PRINCE2 al entorno del proyecto | 243
El equipo de gestión del programa definirá,
realizará el seguimiento y gestionará los beneficios
y el Plan de Revisión de Beneficios del proyecto
será parte del plan de realización de los beneficios
del programa.
19.4.1.2 Organización
El marco Managing Successful Programmes
(MSP) de OGC define una junta de programa
que incluye un Propietario Responsable Principal
(Senior Responsible Owner) del programa, un
gerente del programa, uno o más gerentes de
cambios comerciales, representantes de funciones
corporativas según sea necesario (por ej., recursos
humanos, finanzas), el proveedor principal y los
Ejecutivos de proyecto que estarán a cargo de los
proyectos dentro del programa.
El Propietario Responsable Principal del programa
es la persona individual con responsabilidad
general de asegurar que un programa cumpla sus
objetivos y entregue los beneficios previstos. Es
probable que el Propietario Responsable Principal
del programa confirme el nombramiento del
Ejecutivo del proyecto.
El gerente del programa es responsable del
establecimiento y de la gestión diaria y la
entrega del programa en nombre del Propietario
Responsable Principal del programa.
El gerente de cambios comerciales es responsable
de la definición y gestión de los beneficios durante
toda la vida del programa. Este rol constituye
un enlace entre el programa y las operaciones
comerciales a fin de asegurar que la organización
adopte las potencialidades entregadas por los
proyectos con miras a lograr el resultado final
deseado y sus beneficios subsiguientes.
Es necesario integrar las estructuras de los equipos
de gestión del proyecto y del programa de modo
tal que:
■■ Haya líneas de responsabilidad claras desde los
niveles superiores a los inferiores (es decir, está
claro que cada persona rinde cuentas a alguien)
■■ Se evite la duplicación
■■ Los informes y las revisiones sean eficientes
(por ejemplo, cuatro proyectos dentro de un
programa tienen miembros de la Junta de
Proyecto en común y al alinear los límites de
fase se reúnen colectivamente para realizar
evaluaciones al final de fase para los cuatro
proyectos como parte de una revisión del
programa).
La integración de los roles podría incluir que:
■■ El gerente del programa sea el Ejecutivo de uno
o más de los proyectos
■■ Un gerente de cambios comerciales del
programa desempeñe el rol de Usuario Principal
del proyecto (o que haga aportaciones al
nombrarse el Usuario Principal) para uno o
más de los proyectos o que sea el Ejecutivo del
proyecto para uno o más de los proyectos
■■ El programa facilite el Apoyo al Proyecto
■■ La autoridad de diseño del programa (si se
utiliza) desempeñe el rol de Autoridad de
Cambios o de Garantía del Proyecto para uno
o más de los proyectos ya que el propósito de
una autoridad de diseño a nivel de programa
es asegurar que haya alineación y control
apropiados cuando se están planificando e
implementando cambios.
La selección de la estructura y de los
nombramientos dependerá de la escala y la
complejidad del programa. Es necesario evaluar
las ventajas y desventajas de la elección de la
estructura organizativa y de los nombramientos,
junto con sus consecuencias. Por ejemplo, en
la Figura 19.4, donde el gerente del programa
también es el Ejecutivo de uno de los proyectos
dentro del programa, se debe considerar la manera
en que se presentarán las excepciones entre el
proyecto y el programa y si es necesario establecer
cualquier mecanismo de garantía adicional.
Véanse dos ejemplos en las Figuras 19.3 y 19.4.
La Estrategia de Gestión de la Comunicación
del proyecto se derivará de la estrategia para
la participación de las partes interesadas del
programa, siendo las comunicaciones controladas
y calendarizadas como parte del plan de
comunicaciones del programa. El programa podrá
realizar el análisis de las partes interesadas para
el proyecto, o el programa podría requerir que
el proyecto tome la iniciativa con ciertos grupos
de partes interesadas con los que tiene buenas
relaciones.
244 | Adaptación de PRINCE2 al entorno del proyecto

Junta de Programa

Propietario
Responsable
Principal

Gerente(s) de Ejecutivo del Ejecutivos del

Gerente del Proyecto Autoridad
Cambios Proyecto
Programa (Proyectos B, C, etc.) de Diseño
Comerciales (Proyecto A)

nombra(n) al
Junta de Proyecto para el Proyecto A

Usuario Principal Ejecutivo Proveedor Principal

Autoridad Project Garantía

de Cambios Manager del Proyecto

Rol Apoyo al
combinado Proyecto

Rol Team Team Team

combinado Manager Manager Manager

Figura 19.3 Estructura organizativa con el Ejecutivo como miembro de la junta de programa y el gerente
de cambios comerciales pertinente siendo quien nombra al Usuario Principal

Junta de Programa

Propietario
Responsable
Principal

Gerente de Gerente de Gerente de

Gerente del Autoridad
Cambios Cambios Cambios
de Diseño
Programa
Comerciales A Comerciales B Comerciales C

Junta de Proyecto

Usuario Principal Ejecutivo Proveedor Principal

Autoridad Project Garantía

Rol Manager del Proyecto
de Cambios
combinado

Rol Apoyo al
combinado Proyecto

Rol Team Team Team

combinado Manager Manager Manager

Figura 19.4 Estructura organizativa con el gerente del programa en calidad de Ejecutivo del proyecto y el
rol de Usuario Principal del proyecto a cargo del gerente de cambios comerciales pertinente
 Adaptación de PRINCE2 al entorno del proyecto | 245
19.4.1.3 Calidad
La Estrategia de Gestión de la Calidad del proyecto
se deriva de la Estrategia de Gestión de la Calidad
del programa.
Los miembros del equipo de gestión del programa
podrían llevar a cabo las actividades de garantía de
calidad y de control de calidad.
La autoridad a cargo del diseño del programa
podría proporcionar asesoramiento y orientación
al Project Manager sobre cualquier método de
calidad a ser utilizado.
19.4.1.4 Planes
Cualquier norma específica que los planificadores
del proyecto deban cumplir se describirá en la
estrategia de seguimiento y control del programa.
La actividad de planificación del proyecto para
diseñar el plan asegurará que el proyecto adopte
tales normas y herramientas.
El programa podría contar con planificadores
dedicados que pueden ayudar al Project Manager
a preparar y mantener el Plan de Proyecto y los
Planes de Fase.
La red de dependencia del programa detallará
la manera en que otros proyectos dentro del
programa están utilizando los productos a entregar
de cada proyecto. Cualquier dependencia al o del
proyecto debe ser incorporada a los planes del
proyecto.
19.4.1.5 Riesgo
La Estrategia de Gestión del Riesgo del proyecto se
derivará de la Estrategia de Gestión del Riesgo del
programa. Esto incluirá definir un conjunto común
de categorías de riesgo, escalas de riesgo (para
probabilidad, impacto y proximidad), cualquier
técnica de evaluación del riesgo (tal como valor
monetario previsto), la tolerancia de riesgo a nivel
de proyecto y los mecanismos para presentar una
excepción respecto de riesgos al nivel de programa.
19.4.1.6 Cambio
La Estrategia de Gestión de la Configuración del
proyecto se derivará de la estrategia de gestión
de la información del programa. La estrategia de
gestión de la información define la manera en
que se deben mantener las interacciones entre
proyectos (por ejemplo, de modo que cualquier
cambio en este proyecto que pudiese afectar a
uno o más proyectos se registre y se presente una
excepción al respecto).
El procedimiento de control de cambios del
proyecto se derivará de la estrategia de resolución
de cuestiones del programa. Esto definirá la
manera en que se presenta una excepción al nivel
de programa respecto de los cambios en el alcance
o entrega que apartan al proyecto de sus límites
de tolerancia o que afectan los beneficios del
programa o los planes del programa.
La Autoridad de Cambios del proyecto podría
incluir a la autoridad de diseño del programa.
19.4.1.7 Progreso
La estrategia de seguimiento y control del
programa podría influir en la formalidad, la
frecuencia y el contenido de las revisiones y los
informes del proyecto y cualquier norma de gestión
del proyecto que se ha de cumplir.
El programa definirá tolerancias de tiempo y de
coste a nivel de proyecto.
El plan del programa influirá en la cantidad
y duración de las fases de gestión. Quizás sea
deseable o necesario alinear las evaluaciones al
final de fase a los hitos del programa (por ejemplo,
el final de un tramo). El programa incluso podría
definir un conjunto de fases de gestión modelo que
todos los proyectos dentro del programa tendrán
que utilizar.
19.4.2 Procesos
Dentro del marco Managing Successful
Programmes de OGC, el proceso de la Entrega de
Capacidad dentro de Gestión de los Tramos está
totalmente centrado en el inicio, seguimiento y
cierre de proyectos dentro del programa. No es
necesario adaptar este proceso al trabajar con
PRINCE2.
El proceso de PRINCE2 que se verá más afectado
por trabajar en un programa será el de la Puesta en
Marcha de un Proyecto.
El programa podría realizar casi la totalidad de este
proceso. El programa: nombrará al Ejecutivo y al
Project Manager, revisará las lecciones anteriores,
diseñará y nombrará al equipo de gestión del
proyecto y probablemente preparará el Expediente
del Proyecto. El Project Manager será, sin embargo,
responsable de preparar el Plan de la Fase de
Inicio. En este contexto, no se trata tanto de que el
246 | Adaptación de PRINCE2 al entorno del proyecto

Tabla 19.2 Ejemplos de proyectos de diferentes escalas

Escala del proyecto Características Aplicación de PRINCE2

Alta Programa Transformación comercial Se debería utilizar un marco para gestión

de programas tal como Managing Successful
Programmes de OGC. PRINCE2 se podrá
utilizar para gestionar proyectos dentro del
programa

Proyecto de Riesgo, coste, importancia, visibilidad Fases de entrega múltiples

enormes altos
Junta de Proyecto Extendida (por ej.,
proporciones Múltiples organizaciones grupos de usuarios/proveedores)
Multidisciplinario (por ej., construcción, Team Managers probablemente como un
TI y cambio comercial) rol independiente
Internacional Apoyo al Proyecto probablemente como un
rol independiente
Productos de gestión individuales
Proyecto normal Riesgo, coste, importancia, visibilidad Una o más fases de entrega
medios
Junta de Proyecto modelo
Relación comercial de cliente/
proveedor Team Managers opcionalmente como un
rol independiente
Múltiples sedes
Apoyo al Proyecto opcionalmente como
un rol independiente
Algunos productos de gestión combinados
Proyecto simple Riesgo, coste, importancia, visibilidad Fase de entrega única
bajos Junta de Proyecto simple
Organización única
El Project Manager desempeña el rol
Sede única de Team Manager
El Project Manager desempeña el rol
de Apoyo al Proyecto
Productos de gestión combinados
Tarea Si hay una Junta de Proyecto compuesta Tratar como un Paquete de Trabajo que
por un solo miembro (y típicamente el entrega uno o más productos. Utilizar
Ejecutivo es el gerente de línea del Paquetes de Trabajo, Descripciones de
Project Manager) normalmente Productos, Archivos/Registros e Informes
se podría tratar como una tarea del Punto de Control
El Project Manager también podría ser
la persona que realiza el trabajo
Los costes podrían estar dentro del
presupuesto ‘habitual’
Justificación comercial sencilla –
por ej., respuesta a una instrucción
Baja
 Adaptación de PRINCE2 al entorno del proyecto | 247
proceso de la Puesta en Marcha de un Proyecto no
se realice, sino simplemente de que será realizado
principalmente por la gestión del programa.
19.4.3 Productos de gestión
Confusamente, hay numerosos productos de
gestión que existen tanto para el proyecto como
para el programa; por ejemplo, la Estrategia de
Gestión de la Calidad. En un entorno de programa,
quizás sea deseable añadir la palabra ‘proyecto’
y ‘programa’ al producto de gestión a fin de
establecer la diferencia (por ejemplo Estrategia de
Gestión de la Calidad del proyecto o del programa).
Otra consideración sería hacer que las plantillas
de los documentos del proyecto y del programa
sean muy diferentes en su estilo de modo que sea
inmediatamente evidente dónde son de aplicación.
Se debe considerar si los archivos y registros del
proyecto se mantendrán localmente al proyecto,
o si el programa los mantendrá centralmente.
Por ejemplo, será necesario elegir si habrá un
solo Registro de Riesgos, administrado por el
programa para los riesgos a nivel de programa y
para todos los riesgos para cada proyecto dentro
del programa, o si cada proyecto debe mantener su
propio Registro de Riesgos. Si se elige esto último,
la Estrategia de Gestión del Riesgo del proyecto
debe definir la manera en que los riesgos a nivel de
programa que el proyecto identifique y registre se
elevan al Registro de Riesgos del programa. De la
misma manera, la Estrategia de Gestión del Riesgo
del programa debe definir mecanismos para que
los riesgos del proyecto identificados y registrados
a nivel de programa se transfieran a un documento
de nivel apropiado, como el Registro de Riesgos del
proyecto.
19.5 Escala del proyecto
PRINCE2 se puede utilizar cualquiera sea la escala
del proyecto. La escala de un proyecto es relativa
al tamaño y a la experiencia de la organización
receptora del proyecto – por ej., un proyecto
cuyo presupuesto es de €10 millones podría ser
un proyecto simple para una organización o un
proyecto de enormes proporciones para otra.
La escala se relaciona no sólo con el tamaño del
proyecto (a menudo medido en términos de
tiempo, dinero y personal) sino también con el
contexto de la complejidad, nivel de riesgo e
importancia del proyecto.
Las organizaciones deben considerar calibrar
la escala de sus proyectos. La Tabla 19.2 ilustra
un enfoque sencillo para la categorización de
proyectos y ofrece algunas sugerencias sobre la
manera en que PRINCE2 se podría adaptar.
En la sección 19.5.1 se ofrece orientación sobre la
adaptación de PRINCE2 para un proyecto simple.
19.5.1 Proyecto simple
Como ya se ha dicho anteriormente, la escala de un
proyecto es relativa a la organización y al contexto.
No obstante, hay algunos puntos que es útil
considerar para un proyecto que una organización
considera simple.
Una pregunta que se hace a menudo es: ¿qué
elementos de PRINCE2 se pueden flexibilizar en
proyectos simples? No hay una respuesta fácil a
esta pregunta. Aun los proyectos simples varían
enormemente en su tipo y estilo.
Ante todo, es importante recordar que los
proyectos simples también deben cumplir los
siete principios de PRINCE2 si el proyecto se ha
de gestionar utilizando PRINCE2. Es en la manera
en que se utilizan las temáticas, los procesos y los
productos de gestión que PRINCE2 se ‘adapta’.
En términos generales, se puede considerar que
el propósito de PRINCE2 es reducir el riesgo de
que el proyecto fracase. Así, cuando se flexibiliza
cualquier elemento de PRINCE2, se debe considerar
que se está añadiendo riesgo.
19.5.1.1 Temáticas
La temática más afectada por proyectos simples es
la temática de la Organización:
■■ Adaptar el tamaño del equipo de gestión del
proyecto consiste, fundamentalmente, en
consolidar roles y funciones. Los roles se pueden
combinar pero no se deben eliminar
■■ Debido a que tanto el rol de Ejecutivo como el
de Usuario Principal son del entorno del cliente,
a menudo se pueden combinar
■■ Como es probable que el Project Manager
trabaje más de cerca con la Junta de Proyecto
que en proyectos más grandes y más complejos,
los miembros de la Junta de Proyecto a menudo
están en una mejor posición para realizar su
propia Garantía del Proyecto, más bien que
nombrar a otra persona para que desempeñe
este rol
248 | Adaptación de PRINCE2 al entorno del proyecto
■■ Para equipos pequeños quizás no sea necesario
nombrar Team Managers. El Project Manager
de un proyecto pequeño puede asumir esas
responsabilidades
■■ El Project Manager podrá asumir el rol de
Apoyo al Proyecto y ser un miembro del
equipo. En este caso, el Project Manager debe
necesariamente equilibrar el esfuerzo de
gestionar el proyecto y el esfuerzo de realizar
cualquier trabajo para el proyecto.
Para las otras temáticas, las exigencias mínimas son:
■■ Business Case – Alguna forma de justificación
comercial, sin importar cómo se documenta ésta
■■ Planes – Descripciones de Productos para los
principales productos a entregar y un plan
simple, bajo la forma de un diagrama, de
quién participa en la producción, revisión y
aprobación de los productos, junto con los hitos
principales. A menudo se hace referencia a esto
como una lista de productos (véase un ejemplo
del resumen de la Descripción de Producto para
un Plan en el Apéndice A)
■■ Calidad – Comprensión de los niveles de calidad
requeridos en el proyecto y de los productos del
proyecto
■■ Riesgo – Un análisis de los riesgos a los cuales
se enfrenta el proyecto, las medidas que se
tomarán para implementar respuestas al riesgo
y comunicación del estado del riesgo mediante
Informes del Punto de Control e Informes de
Desarrollo
■■ Cambio – Un método simple para controlar
cambios en el proyecto y para gestionar la
configuración de los productos que se están
entregando – por ejemplo, identificación simple
de productos y normas para control de versión
con arreglos seguros para el almacenamiento
de los productos del trabajo
■■ Progreso – Cierta forma de controles
convenidos y exigencias de presentación de
informes (ya sea escritos o verbales).
19.5.1.2 Procesos
Todos los procesos mantienen su pertinencia aun
en proyectos simples. Sin embargo, el proceso de
la Puesta en Marcha de un Proyecto, normalmente,
puede ser manejado de una manera menos formal.
El Ejecutivo y el Project Manager deben, sin
embargo, evitar la tentación de dejarlo totalmente
de lado. En algunos casos podría ser apropiado
combinar los procesos de la Puesta en Marcha de
un Proyecto y del Inicio de un Proyecto (es decir,
crear la Documentación de Inicio del Proyecto
directamente del mandato y saltarse la producción
de un Expediente del Proyecto).
19.5.1.3 Productos de gestión
La elección del formato del producto de gestión
puede ayudar a reducir el esfuerzo de gestión del
proyecto para un proyecto pequeño, por ejemplo:
■■ La Junta de Proyecto podría decidir que
algunos o todos los informes se transmitirán
verbalmente y/o que la información y las
decisiones también se comunicarán verbalmente
en vez de celebrar reuniones formales. En tales
casos, el Project Manager debe, como mínimo,
documentar el intercambio en el Archivo Diario
ya que aquello que la gente recuerda de un
acuerdo hecho verbalmente puede ser diferente
semanas e incluso unos días más tarde
■■ Los informes podrían tomar la forma de un
mensaje de correo electrónico
■■ La Documentación de Inicio del Proyecto podría
ser un conjunto de diapositivas de presentación.
También se deberá considerar la creación de
documentos que físicamente incluyan más de
un producto de gestión. Es posible gestionar un
proyecto PRINCE2 pequeño con tan sólo cuatro
conjuntos de documentación:
■■ La Documentación de Inicio del Proyecto, que
incluye:
●● El Expediente del Proyecto
●● El Business Case
●● La Estrategia de Gestión del Riesgo
●● La Estrategia de Gestión de la Calidad
●● La Estrategia de Gestión de la Configuración
●● La Estrategia de Gestión de la Comunicación
●● El Plan de Proyecto, que incluye:
●● La Descripción del Producto del Proyecto
●● Las Descripciones de Productos
●● El Plan de Revisión de Beneficios
■■ Los Informes de Desarrollo, que incluyen:
●● El Informe sobre el Estado de los Productos
■■ El Archivo Diario, que incluye:
●● Las cuestiones
●● Los riesgos
●● Las lecciones
●● Las actividades de gestión de la calidad
planificadas y reales
●● Las Fichas de Elementos de Configuración
 Adaptación de PRINCE2 al entorno del proyecto | 249
■■ El Informe al Final de Proyecto, que incluye:
El Informe sobre las Lecciones.
●●
Los siguientes productos de gestión podrían no
necesitarse:
■■ Plan de la Fase – Si hay sólo una fase de
entrega, los detalles del Plan de la Fase se
podrán incluir en el Plan de Proyecto
■■ Informes del Punto de Control – Si no hay Team
Managers, quizás no se necesiten Informes del
Punto de Control (aunque el Project Manager
podría solicitar a miembros individuales del
equipo que los proporcionen)
■■ Paquetes de Trabajo – Podrían sólo ser
apropiados cuando el proyecto tiene Team
Managers. Cuando sólo hay un Project
Manager, el Plan de la Fase podría ser
suficiente. Sin embargo, aun en esos casos, el
Project Manager podría elegir utilizar Paquetes
de Trabajo como un control para miembros
individuales del equipo
■■ Informe al Final de Fase – Si hay sólo una fase
de entrega, el final de esa fase también es el
final del proyecto y sólo se requiere un Informe
al Final de Proyecto
■■ Informe de Cuestiones – Si los detalles de la
cuestión están adecuadamente registrados en el
Registro de Cuestiones (o en el Archivo Diario),
quizás no haya necesidad de un Informe de
Cuestiones.
Ejemplo de productos de gestión
Habiendo decidido combinar los procesos de la
Puesta en Marcha de un Proyecto y del Inicio
de un Proyecto para un proyecto pequeño,
no se produjo un Expediente del Proyecto;
en cambio, el equipo de gestión del proyecto
utilizó el mandato de proyecto para producir
Documentación de Inicio del Proyecto simple. La
Documentación de Inicio del Proyecto incluía un
Plan de Proyecto básico con varias Descripciones
de Productos y detalles de todas las estrategias
y controles a ser aplicados. El Project Manager
eligió utilizar el Archivo Diario para registrar
riesgos, cuestiones, lecciones y resultados de
calidad.
Después de la fase de inicio había solamente una
fase más durante la cual se autorizó una pequeña
cantidad de Paquetes de Trabajo. Mientras éstos
se estaban gestionando, el Project Manager
realizó puntos de control regulares, lo cual
permitió la producción de Informes de
Desarrollo regulares a la Junta de Proyecto.
Al final de esa fase (y por lo tanto del proyecto)
se produjo un Informe al Final de Proyecto
que también incluía la información para el
Informe sobre las Lecciones, las acciones a
realizar recomendadas y un Plan de Revisión de
Beneficios.
19.6 Entorno cliente/proveedor
comercial
PRINCE2 se basa en un entorno de cliente/
proveedor. Supone que habrá un cliente
que especificará el resultado deseado y que
probablemente pagará por el proyecto y un
proveedor que suministrará los recursos y las
competencias para entregar ese resultado. Si la
relación entre el cliente y el o los proveedores es
una relación comercial, se aplicarán consideraciones
adicionales. La principal consideración es reconocer
que hay como mínimo dos conjuntos de:
■■ Razones para realizar el proyecto
■■ Sistemas de gestión (incluyendo métodos de
gestión del proyecto)
■■ Estructuras de gobierno (que posiblemente
requieran que se divulguen diferentes tipos de
datos sobre el proyecto en diferentes puntos en
la vida del proyecto)
■■ Culturas corporativas (por ej., formalidad, toma
de riesgos, etc.).
19.6.1 Temáticas
19.6.1.1 Business Case
En un contexto comercial hay por lo menos dos
Business Cases – el Business Case del cliente y
el Business Case del proveedor. Para que un
proyecto sea exitoso, ambos deben demostrar una
justificación comercial continua. Si el proyecto ya
no es viable, deseable o alcanzable para una de
las partes, el proyecto tendrá dificultades y muy
probablemente fracase por más atractivo que sea
el Business Case para la otra parte.
El Business Case del cliente cubre los beneficios
que el cliente pretende obtener contrastados con
los riesgos y costes que está preparado a sostener.
Se deben incluir los costes internos (de los recursos
250 | Adaptación de PRINCE2 al entorno del proyecto
para el proyecto del cliente y de los recursos para
operaciones y mantenimiento continuos) y los
costes externos (de los bienes y servicios de los
proveedores). Los riesgos deben incluir los riesgos
del proyecto y los riesgos operacionales continuos.
El Business Case del proveedor cubre la parte
del proyecto del cliente que corresponde al
proveedor. Debe contener más información que
simplemente ganar un porcentaje de margen sobre
el total. Desde el punto de vista del proveedor,
se debe considerar la manera en que el proyecto
contribuirá a:
■■ Los objetivos de la venta individual
■■ Los objetivos del plan de ventas al cliente
■■ Los objetivos para el territorio de ventas
■■ Los objetivos del sector del mercado del
proveedor.
Ejemplo de otras consideraciones en el Business
Case de un proveedor
Un equipo de ventas pide al personal directivo
superior del proveedor que otorgue niveles
de descuento más allá de aquellos que están
autorizados a otorgar. El motivo por el cual
se solicita el descuento adicional es para
ganar el proyecto piloto (este proyecto) a fin
de aumentar las posibilidades de lograr un
lanzamiento de producto más amplio. En este
caso, el Business Case del proveedor debe ir
más allá del cumplimiento de las obligaciones
contractuales y cubrir los costes para las
actividades para asegurar que el proveedor
maximice sus oportunidades de venta para el
lanzamiento.
El Business Case de cada una de las partes podría
ser privado o parcialmente privado con respecto a
la otra parte. A menudo, lo más que un proveedor
puede llegar a ver del Business Case del cliente es
una lista de ‘razones’ en una solicitud de cambio.
Sin embargo, dependiendo de la compatibilidad
cultural de las organizaciones del cliente y
del proveedor, dejar que la otra parte vea las
principales razones para la realización del proyecto
(es decir, los beneficios) por lo general significará
un mayor rendimiento para ambas partes.
19.6.1.2 Organización
Una de las principales decisiones a tomar en una
relación cliente/proveedor comercial es quién
debe asumir el rol de Proveedor Principal. Las
consideraciones incluyen:
■■ ¿Es apropiado tener un Proveedor Principal
de una organización externa si la Junta de
Proyecto necesita discutir la financiación de
cambios o de trabajo futuro? O, ¿qué pasa si
lo que se debate es si se termina el contrato
con el proveedor? Una opción podría ser
simplemente excluir al Proveedor Principal de
aquella parte de las revisiones en la que se
discuten los asuntos confidenciales. Otra opción
sería nombrar a la persona responsable del
cumplimiento del contrato del proveedor (por
ej., un gerente de contratos)
■■ ¿Qué sucede si hay varios proveedores? Si
sólo hay unos pocos (digamos tres o cuatro),
se recomienda que todos ellos estén en la
Junta de Proyecto ya que ésta proporciona un
foro para su integración. Si hay más de tres
o cuatro proveedores, el gerente de contrato
responsable del cumplimiento de todos los
contratos con los proveedores podría estar en
la Junta de Proyecto en su nombre, o podría ser
apropiado nombrar un contratista principal
■■ Si el proyecto incluye una fase de adquisición,
¿quién debe desempeñar el rol de Proveedor
Principal si no se ha nombrado al proveedor?
El proyecto podría necesitar que se nombre
a alguien temporalmente para el rol de
Proveedor Principal – quizás del departamento
de adquisiciones o compras del cliente.
Otra decisión principal es quién facilita el Project
Manager. En PRINCE2, el Project Manager
normalmente provendrá de la organización
del cliente y el o los Project Managers de los
proveedores desempeñarán el rol de Team
Managers para el proyecto. Si bien en la
organización del proveedor se podría llamar a los
Team Managers Project Managers, los títulos de los
roles y cargos no se deben confundir. Cabe recordar
que únicamente puede haber un solo Project
Manager.
Podría haber proyectos en los cuales el Project
Manager proviene de la organización del
proveedor. Los clientes podrían elegir mantenerse
alejados del nivel de trabajo y esperar que el
proveedor facilite la gestión para el proyecto. Es
probable que el cliente incremente el rigor en la
Garantía del Proyecto (y de hecho podría elegir
nombrar a uno de sus Project Managers internos
para desempeñar el rol de Garantía del Proyecto).
 Adaptación de PRINCE2 al entorno del proyecto | 251
En este caso, es necesario que quede claro que si
bien el cargo de la persona que realiza la función
de Garantía del Proyecto podría denominarse
Project Manager, esa persona no es el Project
Manager de este proyecto – únicamente puede
haber un Project Manager. Se debe considerar
la dinámica de la Junta de Proyecto si el Project
Manager tiene una línea de rendición de cuentas al
Ejecutivo para el proyecto y una línea jerárquica (o
comercial) al Proveedor Principal.
Las reglas de gobierno del proveedor podrían
significar que deben tratar su Paquete, o paquetes,
de Trabajo dentro del proyecto del cliente como un
proyecto dentro de la organización del proveedor.
Esto podría significar establecer una Junta de
Proyecto del proveedor independiente. Se debe
considerar:
■■ Quién desempeña el rol de Usuario Principal
si no lo desempeña alguien de la organización
del cliente (el gerente de cuentas es un
representante útil en calidad de defensor del
cliente)
■■ La manera en que los roles de Junta de
Proyecto del cliente y del proveedor se
relacionan, es decir, cuál de los miembros de la
Junta de Proyecto del proveedor asume el rol
de Proveedor Principal en la Junta de Proyecto
del cliente. Quienquiera que sea, necesita tener
autoridad para tomar decisiones en nombre del
proveedor al desempeñar el rol de Proveedor
Principal en la Junta de Proyecto del cliente.
Hay diversas maneras de estructurar los roles del
equipo de gestión del proyecto en un contexto de
cliente/proveedor comercial. El objetivo principal es
asegurar que ambas organizaciones establezcan y
mantengan una justificación comercial sólida y que
se cumplan sus respectivas reglas de gobierno.
19.6.1.3 Calidad
La Estrategia de Gestión de la Calidad definirá si
el proyecto se ajustará a los sistemas de gestión
de la calidad del cliente o proveedor, o a una
combinación de ellos.
19.6.1.4 Planes
¿Se puede adjudicar el contrato para la totalidad
del proyecto si la Junta de Proyecto sólo aprueba
la financiación fase por fase? Un enfoque consiste
en que el contrato cubra todo el proyecto, con las
órdenes de compra y los hitos de pago alineados
con cada fase de gestión. Este enfoque alienta a las
organizaciones a considerar qué pasará en el caso
de que el proyecto ya no sea viable para cualquiera
de las dos partes y se cierre prematuramente. Es
prudente desde el punto de vista de adquisiciones
y gestión de ventas asegurar que haya puntos de
ruptura en los contratos para ambas partes.
El cliente puede elegir la manera en que gestiona
las actividades de adquisición – las podrá gestionar
como parte de la fase de inicio (y considerar utilizar
los procesos del Control de una Fase y de la Gestión
de la Entrega de Productos para gestionarlas), o
podrá agregar una fase de adquisición después del
inicio. Gestionar la adquisición dentro de la fase
de inicio reducirá la incertidumbre en los planes.
Sin embargo, podría no haber controles adecuados
en función si las actividades de adquisición son
costosas o llevan mucho tiempo.
PRINCE2 supone que los Paquetes de Trabajo se
acuerdan entre el Project Manager y el Team
Manager y que cualquier Plan del Equipo es
opcional. El Plan del Equipo podría ser privado
con respecto al proveedor ya que podría contener
otra información como dependencias a o de otros
proyectos de clientes, costes del subcontratista, etc.
El Informe del Punto de Control del Team Manager,
con información sobre el progreso en función de
los hitos convenidos en el Paquete de Trabajo,
debería ser suficiente para que el Project Manager
mantenga el Plan de la Fase.
19.6.1.5 Riesgo
En un contexto comercial se podría necesitar más
de un Registro de Riesgos ya que algunos riesgos
del proyecto podrían ser exclusivos solamente a
una parte, con buenos motivos para que éstos
no sean visibles a la otra parte. En los casos en
que se utiliza un Registro de Riesgos conjunto, se
debe tener cuidado de determinar de quién es el
riesgo exactamente y el propietario del riesgo se
deberá nombrar en consecuencia. Por ejemplo,
en un contrato a precio fijo, cualquier exceso en
los costes tendrá un impacto en el Business Case
del proveedor, pero los excesos en los calendarios
normalmente tendrán un impacto sobre todo en el
Business Case del cliente.
19.6.1.6 Cambio
Se debe necesariamente alinear el procedimiento
de control de cambios en la Estrategia de Gestión
de la Configuración y cualquier disposición
252 | Adaptación de PRINCE2 al entorno del proyecto

sobre cambios en el contrato. Si se utiliza un del cliente autoriza el proyecto. La negociación

presupuesto para cambios, será necesario alinearlo del contrato se debe gestionar bajo control de
con los procedimientos de compra del cliente y cambios.
los procedimientos de aprobación comercial del
Un requerimiento adicional es alinear los procesos
proveedor. (Por ejemplo, ¿autorizará el cliente
de aprobación comercial del proveedor con el
el cambio creando nuevas órdenes de compra
proceso de la Puesta en Marcha de un Proyecto
o pedidos de variación en base a la orden de
(aclarando los elementos de la oportunidad) y
compra original, o cubriría la orden de compra
el proceso del Inicio de un Proyecto (aprobando
original tanto el presupuesto para el proyecto
la propuesta). Un enfoque táctico es preparar
y el presupuesto para cambios? ¿Requeriría el
cualquier documentación del proyecto hasta un
procedimiento de aprobación comercial del
estado de ‘borrador final’ durante las actividades
proveedor aprobación independiente de la gestión
anteriores al contrato, para que sea aprobada
para cada solicitud de cambio o la misma está
como parte de la adjudicación del contrato.
cubierta por la aprobación de la gestión para el
proyecto?
19.6.3 Productos de gestión
19.6.1.7 Progreso ¿Cómo se relacionan la Documentación de Inicio
del Proyecto y los Paquetes de Trabajo con el
Es necesario alinear la frecuencia, el formato y la
contrato? Un aspecto de un contrato consiste
formalidad de las revisiones y de la presentación
en describir quién es responsable si cualquiera
de informes con las necesidades en cuanto a
de las dos partes no cumple sus obligaciones
exigencias de gobierno de ambas organizaciones.
contractuales. El contenido de la Documentación
Por ejemplo, podría ser necesario que los Team
de Inicio del Proyecto debe centrarse en la manera
Managers produzcan dos Informes del Punto de
de asegurar que se cumplan las obligaciones
Control, uno para el Project Manager del cliente
de cada parte. Por lo tanto, cumplen diferentes
y uno para la gestión del proveedor. El contenido
funciones. La Documentación de Inicio del Proyecto
de estos informes podría variar (por ejemplo,
podría ser parte de la documentación del contrato,
el Informe del Punto de Control para la gestión
pero se debe tener cuidado ya que se podría
del proveedor podría incluir detalles de nuevas
sofocar la capacidad de adaptación del proyecto si
oportunidades de venta).
la Documentación de Inicio del Proyecto debe pasar
por una revisión legal para cada cambio.
19.6.2 Procesos
Como PRINCE2 se basa en un contexto de cliente/ Para un proveedor externo, el Paquete de Trabajo
proveedor desde la perspectiva del cliente, es poco podría tomar la forma de un contrato vinculante
probable que sea necesario adaptar los procesos y podría requerir modificación a fin de incluir
desde la perspectiva del cliente. cualquier término y condición que se requiera.

Desde el punto de vista de un proveedor, el

cambio principal en los procesos ocurrirá en los
procesos de la Puesta en Marcha de un Proyecto y
del Inicio de un Proyecto. El proceso de la Puesta
en Marcha de un Proyecto tendrá lugar antes del
contrato y generalmente se produce en respuesta
a una solicitud de una propuesta por parte del
cliente. Una parte del proceso del Inicio de un
Proyecto tendrá lugar antes del contrato ya que
el proveedor necesitará formular las estrategias,
los planes y controles a fin de evaluar la viabilidad
y deseabilidad de la venta y los costes y precios
asociados de la solución que se está proponiendo.
El proceso del Inicio de un Proyecto no se
completa, sin embargo, hasta que haya concluido
la negociación del contrato y la Junta de Proyecto
19.7 Proyectos multiorganizativos
El contexto organizativo de los proyectos está
pasando a ser cada vez más complejo. Más
que una simple relación cliente/proveedor de
la que participan dos organizaciones, se están
promoviendo proyectos de los que participan
múltiples organizaciones.
Algunos ejemplos son:
■■ Joint ventures o empresas conjuntas
■■ Investigación colaborativa
■■ Proyectos interdepartamentales
■■ Proyectos intergubernamentales (por ej., la
Unión Europea)
 Adaptación de PRINCE2 al entorno del proyecto | 253
■■ Proyectos interagenciales (por ej., el Programa
de las Naciones Unidas para el Desarrollo)
■■ Alianzas de contratación
■■ Consorcios para ofertar en subastas
■■ Asociaciones.
Podría haber una autoridad principal que encarga
un proyecto (o un cliente principal), pero podría
haber varios clientes. De la misma manera, podría
haber varias organizaciones de proveedores. Esto
podría dar origen a una situación en la cual el
proyecto tiene múltiples propietarios, ya que más
de una organización comparte el control final del
proceso de toma de decisiones. De no convenirse
la base para esta titularidad múltiple, se pone en
peligro al proyecto y se incrementa la posibilidad
de que el proyecto fracase.
La orientación para utilizar PRINCE2 en un
proyecto con múltiples propietarios es similar
al contexto de cliente/proveedor comercial con
respecto a la adaptación de las temáticas, con
cualquier referencia a un ‘contrato’ reemplazada
por ‘acuerdo’. Sin embargo, los arreglos que
se encargan de proyectos multiorganizativos
pueden llegar a ser sumamente complejos. Las
Juntas de Proyecto, por ejemplo, podrían tener
más miembros que los necesarios para tomar
decisiones con efectividad en la práctica. Si no hay
una parte única que prevalezca sobre las otras, se
tiene que llegar a un consenso para cada decisión.
Las Juntas de Proyecto consensuales grandes
trabajan muy lentamente y es probable que el
ritmo de sus proyectos se vea afectado. Si no, los
Project Managers comienzan a tomar decisiones
que están fuera de sus atribuciones. Se debe
considerar adoptar las estructuras organizativas de
gestión de programa para ayudar con la gestión
de los beneficios y la participación de las partes
interesadas.
19.8 Tipo de proyecto
19.8.1 Modelos de ciclo de vida
Muchas industrias o profesiones han desarrollado
modelos de ciclo de vida para determinados
tipos de proyectos, tales como métodos en
cascada o métodos Agile. PRINCE2 funciona
bien con dichos modelos ya que éstos se centran
fundamentalmente en las actividades para crear y
verificar los productos especializados del proyecto
– un aspecto de los proyectos que PRINCE2 no
aborda intencionadamente.
Adaptar PRINCE2 para que funcione con
modelos de ciclo de vida especializados implica
principalmente:
■■ Alinear las fases de gestión con el ciclo de vida
de desarrollo – por ej., diseño, construcción,
prueba, transición
■■ Utilizar tolerancias para que haya
correspondencia con el enfoque del desarrollo
– por ejemplo, los proyectos Agile que utilizan
un enfoque iterativo e incremental tienden a
fijar la escala de tiempo y la calidad (tolerancia
estrecha) y a variar el alcance (tolerancia
amplia)
■■ Integrar cualquier rol especializado a
la estructura del equipo de gestión del
proyecto. Por ejemplo, si el modelo del ciclo
de vida incluye una autoridad de diseño
técnico, ¿debe este rol ser un par del Project
Manager, un Team Manager que rinde
cuentas al Project Manager, o una forma
de Garantía del Proyecto? Debido a que
los roles son simplemente una colección de
responsabilidades, el nombre del rol no es
tan importante, pero es importante que las
responsabilidades definidas por los roles
se asignen a alguna persona dentro de la
organización – y que dicha asignación sea
claramente comprendida por todos los que
participen
■■ Utilizar PRINCE2 para los productos de gestión
del proyecto (por ejemplo, el Expediente del
Proyecto) y utilizar el método especializado
para definir el propósito, el formato, la
composición y los criterios de calidad para
los productos especializados de gestión (por
ejemplo, la definición de la arquitectura de
la solución en Atern de DSDM). Los métodos
especializados también podrían proporcionar
ciertos productos de gestión del proyecto
y por eso es importante identificar cuál de
sus productos de gestión ayudarán con la
creación de los productos especializados (por
ejemplo, un documento de diseño técnico) y
cuáles ayudarán a gestionar el proyecto. Para
cada uno de sus productos de gestión del
proyecto, se debe decidir si se debe utilizar el
equivalente de PRINCE2 o no. La meta es evitar
la duplicación o la falta de documentación
254 | Adaptación de PRINCE2 al entorno del proyecto
■■ Proporcionar enlaces del proceso de la Gestión
de la Entrega de Productos a los procesos de
desarrollo de los productos especializados.
19.8.2 El proyecto en evolución
Investigación financiada por el Engineering and
Physical Sciences Research Council bajo el título
Rethinking Project Management (Winter and
Smith, 2006) identificó que los proyectos de hoy en
día tienden a no empezar con una especificación
previamente definida, pero, en cambio, tienen
especificaciones que evolucionan a medida que
progresa el proyecto. Además, las especificaciones
a menudo son impugnables y se prestan a
negociación durante toda la vida del proyecto. La
inferencia es que, debido a que la especificación se
basa en el Business Case, un proyecto no se puede
poner en marcha con un Business Case previamente
definido.
PRINCE2 no deja de ser compatible con este
enfoque, ya que mantiene su punto de vista que
el Business Case representa la ‘mejor previsión
convenida’ en un punto determinado en el ciclo de
vida de un proyecto, que evolucionará a medida
que el proyecto pase del descubrimiento a la
implementación.
Es probable que el Business Case preliminar
desarrollado antes del proyecto (durante el
proceso de la Puesta en Marcha de un Proyecto)
tenga una amplia previsión de resultados finales
deseados (por ejemplo, una reducción en costes
del 30% al 50%), mientras que es probable que el
Business Case detallado, actualizado a mediados
del proyecto, tenga una previsión mucho más
limitada (por ejemplo, una reducción en costes
del 35% al 40%). Además, también es probable
que el conjunto de productos requeridos para
proporcionar los resultados finales evolucione a
medida que el proyecto progrese.
El valor del Business Case en evolución es que
permite a la organización comprometerse a una
inversión acorde con los beneficios esperados y los
riesgos previstos en ese momento de la evolución
Definición
Investigación
del problema
Figura 19.5 Un ejemplo de un ciclo de vida de un estudio de viabilidad
del proyecto. El Business Case también proporciona
la base para el control y la evaluación del impacto
de los cambios solicitados como resultado del
carácter ‘contencioso y abierto a negociación
durante toda la vida del proyecto’ de los proyectos
modernos.
Los proyectos que implican investigación y
desarrollo, el desarrollo de una política nueva o la
realización de un estudio de viabilidad son típicos
ejemplos de proyectos en evolución. Requieren
consideración específica ya que podrían no
producir ningún beneficio directo (sólo opciones)
y es probable que generen un retorno negativo
sobre la inversión. Es posible valorar las opciones,
lo cual significa que es posible comparar el valor de
un proyecto de investigación y desarrollo con otro,
si se requiere priorización.
19.8.3 El proyecto de viabilidad
En algunas situaciones se podría requerir un
estudio de viabilidad para investigar la situación y
determinar las opciones para el futuro. Utilizando
PRINCE2, un enfoque sería manejar el estudio como
un proyecto independiente y diferente.
La Figura 19.5 muestra el ciclo de vida
relativamente simple de un proyecto para un
estudio de viabilidad. Tiene un Plan de Proyecto,
un Business Case, un conjunto de riesgos y
un producto del proyecto – lo recomendado.
Cada una de las posibles opciones podría variar
enormemente en costes y calendarios. Cada opción
tendría un Plan de Proyecto, un Business Case y un
conjunto de riesgos diferentes, pero al final del
proyecto para un estudio de viabilidad hay una
recomendación.
Si el estudio de viabilidad se considera un proyecto
de por sí, es importante reconocer que el resultado
es solamente una opción, es decir, la opción de
continuar o no. El éxito no se debe juzgar en base
a si la idea es factible sino en base a la habilidad
para tomar una decisión fiable de conformidad con
el análisis realizado.
Desarrollo Presentación de
de opciones recomendaciones
 Adaptación de PRINCE2 al entorno del proyecto | 255
Los proyectos de política son similares a los
proyectos para un estudio de viabilidad en
tanto que el resultado no tiene un valor directo.
Aquello que genera valor es la implementación
subsiguiente de la política. Ya que los proyectos de
política crean productos, PRINCE2 es un método
ideal para aplicar. Sin embargo, una consideración
principal es la naturaleza del Business Case. La
justificación para un proyecto de política podría ser
válida, pero todavía es importante asegurar que
la inversión en el proyecto represente una buena
relación calidad-precio.
19.9 Diferencias sectoriales
Las características de un proyecto son de aplicación
ya sea que la organización esté en el sector público
o en el sector privado. La diferencia principal
estará en el contenido y en la naturaleza del
Business Case. Sin embargo, no se requiere ninguna
adaptación ya que PRINCE2 no estipula aquello
que hace que un Business Case sea viable, deseable
o alcanzable. Estas consideraciones cambiarán del
sector público al sector privado, pero la necesidad
de un Business Case y la manera en que el proyecto
lo utiliza no cambiarán.
Sin embargo, dentro del sector público del Reino
Unido hay dos consideraciones que podrían
requerir adaptación de PRINCE2:
■■ Si el proyecto requiere un Propietario
Responsable Principal (SRO)
(véase la sección 19.9.1)
■■ Si el proyecto está sujeto a una Gateway Review
de OGC (véase la sección 19.9.2).
19.9.1 Propietario Responsable Principal
El Propietario Responsable Principal es la
persona individual totalmente responsable
de asegurar que un proyecto o programa
cumpla sus objetivos y entregue los beneficios
proyectados.
El rol del Propietario Responsable Principal (SRO)
se ha introducido en gran medida en el sector
gubernamental del Reino Unido para proyectos
y programas grandes y en la actualidad se utiliza
cada vez más en otros sectores y países. Se debe
recalcar que el rol de Propietario Responsable
Principal no es un rol de PRINCE2. Sin embargo:
■■ En el contexto de un programa, el Ejecutivo
rendiría cuentas al Propietario Responsable
Principal nombrado para el programa. Quizás
también sea apropiado que el Propietario
Responsable Principal actúe en calidad de
Ejecutivo para proyectos principales dentro del
programa
■■ En el caso en que un Propietario Responsable
Principal es nombrado en el contexto de
un proyecto grande único, la persona que
desempeña el rol de Propietario Responsable
Principal también desempeñaría el rol de
Ejecutivo o nombraría a la persona que ha de
desempeñar el rol de Ejecutivo.
19.9.2 Gateway Review de OGC
La Gateway Review de OGC examina proyectos
en los principales puntos de decisión durante su
ciclo de vida. Mira hacia el futuro para ofrecer una
garantía que pueden progresar con éxito a la fase
siguiente; el proceso es una buena práctica en el
gobierno civil central del Reino Unido, el sector
sanitario, la administración municipal y en defensa
y se ha adoptado en muchos otros países para
proyectos basados en adquisiciones en los cuales se
utilizan fondos públicos.
La Gateway Review de OGC entrega una
‘revisión de expertos’ en la cual practitioners
independientes, externos al proyecto, utilizan su
experiencia y pericia para examinar el progreso y
la probabilidad de la entrega exitosa del proyecto.
Se utiliza para proporcionar una valiosa perspectiva
adicional respecto de las cuestiones a las que el
equipo interno se enfrenta y un desafío externo a
la solidez de los planes y procesos.
La gateway review tiene lugar en diferentes puntos
en el ciclo de vida de un proyecto y el equipo
de revisión necesitará considerar la importancia
relativa de los aspectos individuales de la confianza
en la entrega, dada la fase a la cual el proyecto
haya llegado. Cuando se está estableciendo un
proyecto y éste todavía debe completar su Business
Case, la claridad de cualquier alcance, la viabilidad
de la estructura de gobierno y las adquisiciones
del personal directivo superior podrían dominar la
evaluación. Si bien es probable que esos factores
sean algunos de los determinantes principales
del éxito de cualquier proyecto, más adelante
en su ciclo de vida, la idoneidad de los procesos
que se están utilizando, junto con las aptitudes
256 | Adaptación de PRINCE2 al entorno del proyecto
y las competencias disponibles para el proyecto,
adquirirán más peso.
La gateway review se puede alinear con PRINCE2
de la siguiente manera:
■■ Revisión 1: Justificación comercial – Esta
revisión se centra en torno a la justificación
comercial del proyecto antes de la decisión
principal de aprobar el inicio del proyecto. Se
alinea con la actividad de la Dirección de un
Proyecto de autorizar el inicio
■■ Revisiones 2 y 3: Estrategia para la entrega
y decisión de inversión – Estas revisiones se
alinean con la actividad de la Dirección de un
Proyecto de autorizar un Plan de una Fase o
de Excepción y se centran en asegurar que el
proyecto todavía se requiera, represente una
buena relación calidad-precio y tenga una
estrategia clara para la entrega
■■ Revisión 4: Grado de preparación para
servicio – Esto se centra en torno al grado
de preparación de la organización para
implementar el proyecto y se alinea con la
actividad de la Dirección de un Proyecto de
autorizar un Plan de la Fase o de Excepción.
Otra forma de considerar la alineación sería
organizando las fases del proyecto de modo que
se alineen con las revisiones: inicio (Revisión 1),
fase de adquisición (Revisión 2), fase de diseño
preliminar (Revisión 3), fase de diseño detallado
(Revisión 4), fase de implementación y fase de
entrega.
Una gateway review no es lo mismo que una ‘gate’
o punto de decisión (tal como la evaluación al final
de fase), sino un medio para proporcionar más
garantía a modo de una aportación a la evaluación
al final de fase real en cuanto a la posibilidad de
que el proyecto pueda cumplir sus objetivos. El
coste y el tiempo necesarios para realizar gateway
reviews se debe incluir en el Plan de Proyecto y en
los Planes de Fase.
19.10 Gestión del proyecto -
Cuerpos de Conocimientos
PRINCE2 no se debe confundir con un Cuerpo de
Conocimientos o Body of Knowledge (BoK):
■■ PRINCE2 es un método de gestión del proyecto
integrado que ofrece un conjunto de procesos y
temáticas que se pueden aplicar para gestionar
un proyecto desde el inicio hasta el final
■■ Un Cuerpo de Conocimientos cubre el amplio
espectro de competencias y técnicas de gestión
del proyecto que los Project Managers podrían
necesitar aplicar, tales como dirección y
negociación.
La comparación entre PRINCE2 y un Cuerpo de
Conocimientos o Body of Knowledge (BoK),
tal como el Cuerpo de Conocimientos de la
Association for Project Management, el PMBoK del
Project Management Institute o las Competency
Baselines de la International Project Management
Association, se puede ver en la Tabla 19.3.
Las diferencias entre PRINCE2 (un método) y
un Cuerpo de Conocimientos hacen que sean
sumamente complementarios.
PRINCE2 proporciona un marco de qué se necesita
hacer, por quién y para cuándo. El Cuerpo de
Conocimientos ofrece una serie de técnicas sobre
cómo se pueden hacer estas cosas. Por ejemplo,
en PRINCE2 un paso crítico al crear un plan es la
estimación. PRINCE2 no dice de qué manera la
estimación se debe hacer ya que hay una serie de
técnicas que se pueden aplicar dependiendo del
contexto del proyecto, mientras que un Cuerpo
de Conocimientos ofrece una explicación y un
análisis de la diversidad de técnicas de estimación
disponibles de modo que el planificador pueda
juzgar cuál es la más apropiada para ser utilizada.
La adaptación de PRINCE2 si la organización está
alineada con cualquier Cuerpo de Conocimientos
determinado debe incluir:
■■ Convenir un conjunto único de términos que
serán de aplicación. Por ejemplo, en el Cuerpo
de Conocimientos de la Association for Project
Management, el steering group es equivalente
a la Junta de Proyecto de PRINCE2
■■ Alinear los productos de gestión de
PRINCE2 con cualquier producto de gestión
recomendado por el Cuerpo de Conocimientos.
Por ejemplo, en PMBoK el project charter es
equivalente al Expediente del Proyecto de
PRINCE2.
 Adaptación de PRINCE2 al entorno del proyecto | 257

Tabla 19.3 Comparación entre PRINCE2 y un Cuerpo de Conocimientos

PRINCE2 Cuerpo de Conocimientos
Un método de gestión del proyecto Una amplia colección de ‘buenas prácticas’ para gestión
del proyecto
Prescriptivo No prescriptivo
Un conjunto integrado de procesos y temáticas (no son Cada tema se puede consultar aisladamente de los otros
silos aislados que se pueden aplicar selectivamente)
Cubre todos los roles de gestión del proyecto Orientado a los Project Managers
No cubre las competencias interpersonales Cubre las competencias interpersonales
Hace referencia a las técnicas Describe las técnicas
 A
Apéndice A: Contenido
básico de las
Descripciones de
Productos
Apéndice A: Contenido básico de las
Descripciones de Productos
Este apéndice recoge el contenido básico de las
Descripciones de Productos para los productos de
gestión de PRINCE2. No se trata de descripciones
de productos completas como vienen definidas
por la Descripción de Producto en la sección A.4,
ya que algunos elementos como el método de
calidad variarán de acuerdo con las necesidades del
proyecto. Se proporcionan ejemplos de formato,
pero no se pretende presentarlos como los únicos
formatos posibles. El contenido de una Descripción
de Producto para un producto de gestión se debe
adaptar a las exigencias y al entorno de cada
proyecto. Existen tres tipos de Producto de Gestión:
baselines, fichas e informes.
Los productos de gestión baseline son aquellos
que definen aspectos del proyecto y que una vez
aprobados están sujetos a control de cambios. Son:
■■ A.3 Business Case
■■ A.4 Descripción de Producto
■■ A.5 Descripción del Producto del Proyecto
■■ A.6 Documentación de Inicio del Proyecto
■■ A.7 Estrategia de Gestión de la Calidad
■■ A.8 Estrategia de Gestión de la Comunicación
■■ A.9 Estrategia de Gestión de la Configuración
■■ A.10 Estrategia de Gestión del Riesgo
■■ A.11 Expediente del Proyecto
■■ A.21 Paquete de Trabajo
■■ A.22 Plan (abarca los planes de proyecto, fase y
opcionalmente de equipo)
■■ A.23 Plan de Revisión de Beneficios
Las fichas son productos de gestión dinámicos
que guardan información sobre el progreso del
proyecto. Son:
■■ A.1 Archivo de sobre las Lecciones
■■ A.2 Archivo Diario
■■ A.12 Fichas de un Elemento de Configuración
■■ A.24 Registro de Calidad
■■ A.25 Registro de Cuestiones
■■ A.26 Registro de Riesgos
Los informes son productos de gestión que
proporcionan una instantánea del estado de ciertos
aspectos del proyecto. Son:
■■ A.13 Informe al Final de Fase
■■ A.14 Informe al Final de Proyecto
■■ A.15 Informe de Cuestiones
■■ A.16 Informe de Desarrollo
■■ A.17 Informe de Excepción
■■ A.18 Informe del Punto de Control
■■ A.19 Informe sobre el Estado de los Productos
■■ A.20 Informe sobre las Lecciones.
Aunque las fichas y los informes no están sujetos a
control de cambios siguen los otros aspectos de la
gestión de la configuración, como el control de las
versiones, el almacenamiento seguro, los derechos
de acceso, etc.
Los productos de gestión no son necesariamente
documentos; son bloques de información que
utilizan los procesos de PRINCE2 para que quienes
desempeñan determinados roles puedan llevar a
cabo acciones y/o tomar decisiones.
La mayoría de productos baseline evolucionan
durante las actividades anteriores al proyecto y de
la fase de inicio, como muestra la Figura A1.
A continuación, los productos baseline se revisan
y posiblemente se actualizan al final de cada fase.
Existen productos de gestión que forman parte
de otros productos de gestión de nivel más alto.
En este caso, se mostrarán referencias cruzadas
a la secciones correspondientes del apéndice
(por ejemplo, si se inserta un Informe sobre las
Lecciones en otro informe, habrá una referencia
cruzada a la sección A.20).
A.1 Archivo SOBRE las Lecciones
A.1.1 Propósito
El Archivo sobre las Lecciones se utiliza como
depósito para las lecciones que sirven para
aplicarse a este proyecto o a futuros proyectos.
Algunas lecciones pueden tener su origen en otros
proyectos y se deben registrar en el Archivo sobre
las Lecciones para aplicarlas a las estrategias y
planes del proyecto. Otras lecciones pueden tener
su origen en el propio proyecto – cuando una
nueva experiencia (tanto buena como mala) puede
pasarse a otros por medio del Informe sobre las
Lecciones.
A.1.2 Composición
En cada anotación que se haga en el Archivo sobre
las Lecciones, se deberá indicar lo siguiente:
262 | Apéndice A: Contenido básico de las Descripciones de Productos

Mandato de proyecto Pre-proyecto Fase de inicio

Expediente Documentación de
del Proyecto Inicio del Proyecto

Descripción del Extractos del

Producto del Proyecto Expediente del Proyecto
Contiene
Contiene
Business Case
Business Case (detallado)
preliminar

Estrategia de
Plan de Fase Gestión de la Calidad
(fase de inicio)

Estrategia de
Gestión de la
Configuración

Crea
Estrategia de
Gestión del Riesgo

Estrategia de
Gestión de la
Comunicación

Plan de Proyecto

Descripción del
Contiene Producto del Proyecto

Plan de la Fase Podría ser parte

del Plan de
Proyecto para
proyectos
Contiene pequeños
Descripciones
de Productos

Paquetes de Trabajo

Plan de
Revisión de Beneficios

Figura A1 - Evolución de los productos de gestión baseline

■■ Tipo de lección: define el tipo de lección que se ■■ Datos de la lección: los datos pueden incluir:
anota: ●● Acontecimiento
●● De proyecto – para aplicarse en este ●● Efecto (por ejemplo, impacto económico
proyecto positivo/negativo)
●● Corporativa o de programa – para trasladarla ●● Causas/desencadenante
a la gerencia corporativa o del programa ●● Si existía algún indicador de preaviso
●● Tanto de proyecto como corporativa o del ●● Recomendaciones
programa
 Apéndice A: Contenido básico de las Descripciones de Productos | 263
Si se había identificado anteriormente como
●●
riesgo (amenaza u oportunidad)
■■ Fecha de documentación: la fecha en la que se
documentó inicialmente la lección
■■ Documentado por: el nombre de la persona o
equipo que planteó la lección
■■ Prioridad: remitiéndose a las categorías
escogidas del proyecto.
A.1.3 Derivación
■■ Informes sobre las Lecciones de otros proyectos
■■ Mandato de proyecto o Expediente del
Proyecto
■■ Archivo Diario, Registro de Cuestiones, Registro
de Calidad y Registro de Riesgos
■■ Informes del Punto de Control e Informes de
Desarrollo
■■ Paquetes de Trabajo completados
■■ Planes de Fase actualizados con datos reales
■■ Observación y experiencia de los procesos del
proyecto.
A.1.4 Formato y presentación
Un Archivo sobre las Lecciones puede tener varios
formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Archivo independiente o en forma de
actualizaciones en las actas de revisión del
progreso
■■ Datos introducidos en una herramienta de
gestión de proyectos
■■ Parte de un registro de proyecto integrado
para todos los riesgos, acciones, decisiones,
suposiciones, cuestiones, lecciones, etc.
A.1.5 Criterios de calidad
■■ El estado indica si se han realizado acciones
■■ Las lecciones están identificadas de forma única,
incluyendo el producto al que se refieren
■■ Se define un proceso por el que se debe
actualizar el Archivo sobre las Lecciones
■■ Se controla el acceso al Archivo sobre las
Lecciones
■■ El Archivo sobre las Lecciones se conserva en un
lugar seguro.
A.2 Archivo Diario
A.2.1 Propósito
Un Archivo Diario se utiliza para dejar constancia
de las cuestiones informales, las acciones necesarias
o los acontecimientos importantes no recogidos
en otros registros o archivos de PRINCE2. Cumple
la función de agenda del proyecto para el Project
Manager.
También se puede utilizar como depósito para
cuestiones y riesgos durante el proceso de la Puesta
en Marcha de un Proyecto si no se han creado los
demás registros.
Puede existir más de un Archivo Diario si los Team
Managers deciden tener un Archivo Diario para sus
Paquetes de Trabajo, independiente del Archivo
Diario del Project Manager.
A.2.2 Composición
Un Archivo Diario tiene una composición libre,
pero suele incluir:
■■ Fecha de la anotación
■■ Problema, acción, acontecimiento o comentario
■■ Persona responsable
■■ Fecha de resolución
■■ Resultados.
A.2.3 Derivación
Los datos se introducen cuando el Project Manager
o el Team Manager conside ran apropiado
documentar alguna circunstancia. Con frecuencia,
las anotaciones se basan en pensamientos,
conversaciones y observaciones.
A.2.4 Formato y presentación
Un Archivo Diario puede tener varios formatos,
incluyendo:
■■ Documento u hoja de cálculo
■■ Agenda de escritorio o cuaderno
■■ Agenda/Calendarios/Listas de Tareas
electrónicos
■■ Datos introducidos en una herramienta de
gestión de proyectos.
264 | Apéndice A: Contenido básico de las Descripciones de Productos
A.2.5 Criterios de calidad
■■ Las anotaciones están suficientemente
documentadas para que se puedan comprender
más adelante (una pequeña nota puede tener
sentido en el momento de escribirla pero quizás
no varios meses después)
■■ Siempre se indica la fecha, la persona
responsable y la fecha de resolución
■■ Se han tenido en cuenta los derechos de acceso
del Archivo Diario (por ejemplo, ¿deberían
poder ver el Archivo Diario todas las personas
que trabajan en el proyecto?).
A.3 Business Case
A.3.1 Propósito
Un Business Case se utiliza para documentar la
justificación de realizar un proyecto, basándose en
los costes estimados (costes de desarrollo, ejecución
y costes graduales de uso y mantenimiento en
curso), teniendo en cuenta los beneficios esperados
y sopesándolos con los riesgos asociados.
El Business Case preliminar se prepara en el
proceso de la Puesta en Marcha de un Proyecto y se
perfecciona en el proceso del Inicio de un Proyecto.
El proceso de la Dirección de un Proyecto incluye la
aprobación y consolidación del Business Case.
El Business Case se utiliza en el proceso del Control
de una Fase a la hora de evaluar el impacto de las
cuestiones y los riesgos. Se revisa y actualiza al final
de cada fase de gestión en el proceso de la Gestión
del Límite de una Fase y al final del proyecto en el
proceso del Cierre de un Proyecto.
A.3.2 Composición
■■ Resumen ejecutivo: pone de relieve los puntos
principales del Business Case, que deben incluir
los beneficios importantes y el retorno sobre la
inversión (Return On Investment)
■■ Razones: define las razones para llevar a
cabo el proyecto y explica el modo en que el
proyecto posibilitará el logro de los objetivos y
estrategias de la organización
■■ Opciones comerciales: análisis y recomendación
justificada de las opciones comerciales básicas
de: no hacer nada, hacer lo mínimo o hacer
algo
■■ Beneficios esperados: los beneficios que el
proyecto ofrecerá, expresados en términos
que permitan su medición, teniendo en cuenta
la situación existente antes del proyecto. Los
beneficios deben ser tanto cualitativos como
cuantitativos. Deben clasificarse en beneficios
corporativos o del programa. Se deben fijar
las tolerancias para cada beneficio y para el
conjunto de beneficios. Se debe especificar
cualquier requisito de obtención de los
beneficios
■■ Contrabeneficios previstos: los resultados
percibidos como negativos por una o más
partes interesadas. Los contrabeneficios son
consecuencias concretas de una actividad
mientras que, por definición, un riesgo presenta
cierta incertidumbre acerca de si se va a
concretar. Por ejemplo, la decisión de fusionar
dos elementos de una organización en un
solo lugar físico puede tener beneficios (por
ejemplo, mejor trabajo conjunto), costes (por
ejemplo, la expansión de uno de los dos lugares
físicos) y contrabeneficios (por ejemplo, el
descenso de la productividad durante la fusión).
Los contrabeneficios se tienen que valorar e
incluir en la estimación de la inversión
■■ Calendario: espacio de tiempo durante el que
estará en marcha el proyecto (resumen del
Plan de Proyecto) y el período durante el que
se obtendrán los beneficios. Esta información
se utiliza posteriormente para ayudar a tomar
decisiones sobre la planificación temporal (Plan
de Proyecto, Plan de la Fase y Plan de Revisión
de Beneficios)
■■ Costes: un resumen de los costes del proyecto
(obtenidos del Plan de Proyecto), los costes de
uso y mantenimiento en curso y los planes de
financiación
■■ Evaluación de la inversión: compara el conjunto
de beneficios y contrabeneficios con los costes
del proyecto (obtenidos del Plan de Proyecto)
y los costes graduales de uso y mantenimiento
en curso. El análisis puede hacer uso de técnicas
como el estado de flujo de efectivo, el retorno
de la inversión (ROI), el valor actualizado neto
y la tasa interna de rendimiento y el período
de recuperación de las inversiones. El objetivo
es lograr definir el valor de un proyecto como
inversión. La evaluación de la inversión debe
reflejar cómo se financiará el proyecto
■■ Riesgos principales: proporciona un resumen
de los riesgos principales asociados al proyecto
junto a su probable impacto y a los planes en
caso de que ocurran.
 Apéndice A: Contenido básico de las Descripciones de Productos | 265
A.3.3 Derivación
■■ Mandato de proyecto y Expediente del Proyecto
- razones
■■ Plan de Proyecto - costes y calendario
■■ Usuario(s) Principal(es) – beneficios esperados
■■ El Ejecutivo – relación coste/beneficio
■■ Registro de Riesgos
■■ Registro de Cuestiones.
A.3.4 Formato y presentación
Un Business Case puede tener varios formatos,
incluyendo:
■■ Documento, hoja de cálculo o presentación de
diapositivas
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.3.5 Criterios de calidad
■■ Las razones del proyecto deben ser coherentes
con la estrategia corporativa o del programa
■■ El Plan de Proyecto y el Business Case deben
estar alineados
■■ Los beneficios deben estar claramente
identificados y justificados
■■ Debe quedar claramente reflejado cómo se
materializarán los beneficios
■■ Debe quedar claramente reflejado qué
constituirá un resultado satisfactorio
■■ Debe quedar claro cuál es la opción comercial
preferida y por qué
■■ Cuando sea necesario contar con suministros
externos, debe quedar claro qué fuente es la
preferida y por qué
■■ Debe quedar claramente reflejado cómo se
obtendrá la financiación necesaria
■■ El Business Case incluye criterios económicos y
no económicos
■■ El Business Case incluye costes y riesgos de uso y
mantenimiento, además de costes y riesgos del
proyecto
■■ El Business Case se adecua a las normas de
contabilidad (por ejemplo, a las convenciones
sobre flujo de efectivo y análisis del punto de
equilibrio o Análisis del Punto Muerto)
■■ Los riesgos principales que pueden afectar al
proyecto se indican explícitamente junto a las
respuestas que se proponen.
A.4 Descripción de Producto
A.4.1 Propósito
Una Descripción de Producto se utiliza para:
■■ Comprender en profundidad la naturaleza,
propósito, función y apariencia del producto
■■ Definir quién utilizará el producto
■■ Identificar las fuentes de información o
suministro para el producto
■■ Identificar el nivel de calidad necesario para el
producto
■■ Permitir la identificación de las actividades
necesarias para producir, revisar y aprobar el
producto
■■ Definir el personal o las competencias
necesarias para producir, revisar y aprobar el
producto.
A.4.2 Composición
■■ Identificador: clave única, normalmente
asignada por el método de gestión de la
configuración y que generalmente incluirá el
nombre del proyecto, el nombre del elemento y
el número de versión
■■ Título: nombre con el que se conoce el
producto
■■ Propósito: define la finalidad que tendrá el
producto y quién lo utilizará. ¿Es un medio
para un fin o es un fin en sí mismo? Ayuda a
comprender las funciones del producto y su
tamaño, calidad, complejidad, solidez, etc.
■■ Composición: es una lista de las partes del
producto. Por ejemplo, si el producto fuera
un informe, sería una lista de los capítulos o
secciones previstos
■■ Derivación: ¿cuáles son los productos de los
cuales deriva originalmente este producto?
Ejemplos:
●● un diseño deriva de una especificación
●● un producto se compra a un proveedor
●● la información sobre los beneficios esperados
se obtiene del usuario
●● un producto se obtiene de otro
departamento o equipo
■■ Formato y presentación: las características del
producto. Por ejemplo, si el producto fuera
un informe, se especificaría si el informe
debe ser un documento, una presentación de
diapositivas o un correo electrónico
266 | Apéndice A: Contenido básico de las Descripciones de Productos
■■ Competencias necesarias para el desarrollo:
una indicación de las competencias necesarias
para desarrollar el producto o información que
indique qué sección(es) debe(n) proveer los
recursos para el desarrollo. La identificación de
las personas específicas puede esperar hasta la
planificación de la fase en la que se creará el
producto
■■ Criterios de calidad: ¿qué criterios de calidad se
seguirán para crear el producto y cómo medirán
la calidad quienes inspeccionen el producto
terminado? Puede tratarse de una simple
referencia a una o más normas documentadas
en otro lugar o bien una explicación completa
de los criterios que se deben aplicar. Si el
producto se va a desarrollar y aprobar en sus
distintas condiciones (por ejemplo, maquinaria
desmontada, maquinaria desplazada y
maquinaria reensamblada), los criterios de
calidad deben agruparse de acuerdo con los
que sean de aplicación a cada condición
■■ Tolerancia de calidad: información sobre los
márgenes de los criterios de calidad dentro de
los cuales el producto será aceptable
■■ Método de calidad: el tipo de método de
calidad que se utilizará para comprobar la
calidad o funcionalidad del producto. Por
ejemplo, verificación del diseño, producto
piloto, ensayos, inspecciones o revisiones
■■ Competencias necesarias para la calidad: una
indicación de las competencias necesarias para
aplicar el método de calidad o información
que indique qué área(s) debe(n) proveer los
recursos para la verificación. La identificación
de las personas específicas puede esperar hasta
la planificación de la fase en la que se debe
realizar la inspección de calidad
■■ Responsabilidades de calidad: definen el
productor, revisor(es) y aprobador(es) para el
producto.
A.4.3 Derivación
■■ Estructura jerárquica de productos
■■ Los usuarios finales del producto
■■ Estrategia de Gestión de la Calidad
■■ Estrategia de Gestión de la Configuración.
A.4.4 Formato y presentación
Una Descripción de Producto puede tener varios
formatos, incluyendo:
■■ Documento, presentación de diapositivas,
diagrama o mapa conceptual
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.4.5 Criterios de calidad
■■ El propósito del producto está claro y es
coherente con otros productos
■■ El producto está descrito con un nivel de detalle
suficiente para poder planificar y gestionar su
desarrollo
■■ La Descripción de Producto es concisa pero
suficiente para que el producto pueda ser
producido, revisado y aprobado
■■ Se ha identificado claramente quién es
responsable del desarrollo del producto
■■ La responsabilidad sobre el desarrollo
del producto es coherente con los roles y
responsabilidades descritos en la estructura del
equipo de gestión del proyecto y la Estrategia
de Gestión de la Calidad
■■ Los criterios de calidad son coherentes con
las normas de calidad del proyecto, las listas
estándar de productos y los criterios de
aceptación
■■ Se pueden utilizar los criterios de calidad para
determinar si el producto puede desempeñar su
función
■■ Los tipos de inspección de calidad necesarios
permiten verificar si el producto cumple los
requisitos de calidad establecidos
■■ El/Los Usuario(s) Principal(es) confirma(n) que
la definición que se hace en la Descripción de
Producto de sus requisitos para el producto es
una definición correcta
■■ El/Los Proveedor(es) Principal(es) confirma(n)
que es posible cumplir con los requisitos
del producto definidos en la Descripción de
Producto.
 Apéndice A: Contenido básico de las Descripciones de Productos | 267
A.5 Descripción del Producto del
Proyecto
A.5.1 Propósito
La Descripción del Producto del Proyecto es una
clase especial de Descripción de Producto que
define lo que el proyecto debe conseguir para ser
aceptado. Se utiliza para:
■■ Conseguir el consentimiento del usuario
respecto del alcance y las exigencias del
proyecto
■■ Definir las expectativas de calidad del cliente
■■ Definir los criterios de aceptación, métodos y
responsabilidades del proyecto.
La Descripción de Producto para el producto del
proyecto se crea en el proceso de la Puesta en
Marcha de un Proyecto como parte de la actividad
de determinación inicial del alcance y se desarrolla
durante el proceso del Inicio de un Proyecto
cuando se crea el Plan de Proyecto. Está sujeta a
control de cambios formal y debería controlarse en
los límites de fase (durante la Gestión de los Límites
de Fase) para ver si es necesario algún cambio.
Se utiliza en el proceso del Cierre de un Proyecto
como parte de la verificación de que el proyecto ha
conseguido lo que se esperaba del mismo y que se
han cumplido los criterios de aceptación.
A.5.2 Composición
■■ Título: nombre con el que se conoce el proyecto
■■ Propósito: define la finalidad que tendrá el
producto del proyecto y quién lo utilizará.
Ayuda a comprender las funciones del producto
y su tamaño, calidad, complejidad, solidez, etc.
■■ Composición: descripción de los principales
productos que el proyecto debe entregar
■■ Derivación: ¿cuáles son los productos originales
de los cuales deriva este producto? Ejemplos:
●● Productos existentes que se modificarán
●● Especificaciones de diseños
●● Informe de viabilidad
●● Mandato de proyecto
■■ Competencias necesarias para el desarrollo:
indicación de las competencias necesarias para
desarrollar el producto o información que
indique qué área(s) debe(n) proveer los recursos
para el desarrollo
■■ Expectativas de calidad del cliente: descripción
de la calidad esperada para el producto del
proyecto y las normas y procesos que se tendrán
que aplicar para conseguir esa calidad. Tendrán
un impacto sobre todos los aspectos del
desarrollo del producto y por lo tanto sobre el
tiempo y el coste. Las expectativas de calidad se
registran en las conversaciones con el cliente.
Cuando sea posible, se debe asignar una
prioridad a las expectativas
■■ Criterios de aceptación: lista priorizada de
criterios que el producto del proyecto debe
cumplir para que sea aceptado por el cliente,
es decir, definiciones susceptibles de medición
sobre los atributos que se deben aplicar
al conjunto de productos para que éstos
sean aceptables para las principales partes
interesadas (y, en particular, para los usuarios
y las organizaciones de uso y mantenimiento).
Ejemplos: facilidad de utilización, facilidad de
mantenimiento o soporte, apariencia, funciones
principales, costes de desarrollo, costes de
operación, capacidad, disponibilidad, fiabilidad,
seguridad, precisión o rendimiento
■■ Tolerancias de calidad a nivel de proyecto:
especifican cualquier tolerancia que sea de
aplicación a los criterios de aceptación
■■ Método de aceptación: indica el modo en que
se confirmará la aceptación. Puede tratarse
simplemente de una confirmación de que
todos los productos del proyecto han sido
aprobados o puede implicar la descripción de
métodos complejos de entrega del producto
del proyecto, incluyendo cualquier entrega por
fases de los productos del proyecto
■■ Responsabilidades de aceptación: definen quién
es responsable de confirmar la aceptación.
A.5.3 Derivación
■■ Mandato de proyecto
■■ Conversaciones con el Usuario Principal y el
Ejecutivo – por ejemplo, en talleres de trabajo
para la determinación del alcance
■■ Solicitud de propuesta (si se trata de un
entorno comercial cliente/proveedor).
A.5.4 Formato y presentación
Una Descripción de Producto para el producto del
proyecto puede tener varios formatos, incluyendo:
■■ Documento, presentación de diapositivas,
diagrama o mapa conceptual
■■ Datos introducidos en una herramienta de
gestión de proyectos.
268 | Apéndice A: Contenido básico de las Descripciones de Productos
A.5.5 Criterios de Calidad
■■ El propósito está claro
■■ La composición define el alcance completo del
proyecto
■■ Los criterios de aceptación forman la lista
completa con la que se evaluará el proyecto
■■ Los criterios de aceptación tienen en cuenta
las exigencias de todas las partes interesadas
principales (por ejemplo, organizaciones de uso
y mantenimiento)
■■ La Descripción del Producto del Proyecto indica
cómo los usuarios y las organizaciones de uso
y mantenimiento evaluarán si el producto o
productos finales son aceptables:
●● Todos los criterios se pueden medir
●● Cada criterio es realista individualmente
●● Los criterios en conjunto son realistas y
coherentes. Por ejemplo, puede que no sea
posible combinar buena calidad, entrega
rápida y bajo coste
●● Todos los criterios se pueden probar durante
el ciclo de vida del proyecto (por ejemplo,
el flujo máximo de una bomba de agua) o
por cálculos sustitutivos que proporcionen
indicadores razonables acerca del
cumplimiento post-proyecto de los criterios
de aceptación (por ejemplo, una bomba de
agua que cumple con las normas sobre la
fiabilidad del diseño y la fabricación)
■■ En las expectativas de calidad se ha tenido en
cuenta:
●● Las características de las principales
exigencias de calidad (por ejemplo, rápido/
lento, grande/pequeño, nacional/mundial)
●● Los elementos del sistema de gestión de
calidad del cliente que se deban utilizar
●● Cualquier otra norma que se deba utilizar
●● El nivel de satisfacción de clientes/personal
que se debería obtener si se realizara un
sondeo.
A.6 Documentación de Inicio del
Proyecto
A.6.1 Propósito
El propósito de la Documentación de Inicio del
Proyecto es definir el proyecto para constituir la
base para su gestión y una evaluación de su éxito
general. La Documentación de Inicio del Proyecto
proporciona la dirección y alcance del proyecto y,
junto al Plan de la Fase, constituye el “contrato”
entre el Project Manager y la Junta de Proyecto.
Los tres usos principales de la Documentación de
Inicio del Proyecto son:
■■ Asegurarse de que el proyecto cuente con
una base firme antes de solicitar a la Junta de
Proyecto que adopte cualquier compromiso
importante respecto de la realización del
proyecto
■■ Servir de documento base con el que la Junta
de Proyecto y el Project Manager puedan
evaluar el progreso, las cuestiones y la
viabilidad continua del proyecto
■■ Servir de fuente de referencia única sobre
el proyecto, de modo que las personas que
se incorporen a la “organización temporal”
puedan saber rápida y fácilmente de qué trata
el proyecto y cómo se gestiona.
La Documentación de Inicio del Proyecto es
un producto dinámico y debe reflejar en cada
momento el estado actual, los planes y los
controles del proyecto. Se deberán actualizar y
crear nuevas versiones baseline de los productos
que la componen, si es necesario, al final de cada
fase, para reflejar el estado actual de las partes
que lo componen.
La versión de la Documentación de Inicio
del Proyecto que se utilizó para obtener la
autorización del proyecto se conserva como la
base sobre la que se evaluará posteriormente el
rendimiento, cuando se cierre el proyecto.
A.6.2 Composición
A continuación se muestra una lista de contenidos
para la Documentación de Inicio del Proyecto.
Nótese que los dos primeros puntos (definición del
proyecto y enfoque del proyecto) se extraen del
Expediente del Proyecto.
■■ Definición del proyecto: explica lo que el
proyecto tiene que conseguir. Debe incluir:
●● Antecedentes
●● Objetivos del proyecto y resultado deseado
●● Alcance del proyecto y exclusiones
●● Restricciones y suposiciones
●● El usuario o usuarios y cualquier parte
interesada conocida
●● Interacciones
■■ Enfoque del proyecto: define la solución
escogida que se utilizará en el proyecto para
desarrollar la opción comercial del Business
 Apéndice A: Contenido básico de las Descripciones de Productos | 269
Case elegida, teniendo en cuenta el entorno
operativo al que debe ajustarse la solución
■■ Business Case (véase la sección A.3): describe
la justificación del proyecto, basándose en los
costes, riesgo y beneficios estimados
■■ Estructura del equipo de gestión del proyecto:
un gráfico que muestra quién participará en el
proyecto
■■ Descripción de los roles: para el equipo de
gestión del proyecto y cualquier otro recurso
principal
■■ Estrategia de Gestión de la Calidad (véase la
sección A.7): describe las técnicas y normas
de calidad que se deben aplicar, así como las
responsabilidades en cuanto al logro de los
niveles de calidad exigidos
■■ Estrategia de Gestión de la Comunicación
(véase la sección A.8): define las partes
interesadas en el proyecto y los medios y la
frecuencia de las comunicaciones entre las
mismas y el proyecto
■■ Estrategia de Gestión de la Configuración
(véase la sección A.9): describe cómo y cuándo
se controlarán y protegerán los productos del
proyecto
■■ Estrategia de Gestión del Riesgo (véase la
sección A.10): describe las técnicas y normas
específicas de gestión de riesgo que se deben
aplicar, así como las responsabilidades en
cuanto al desarrollo de un procedimiento eficaz
de gestión del riesgo
■■ Plan de Proyecto (véase la sección A.22):
describe cómo y cuándo se tienen que cumplir
los objetivos del proyecto, especificando los
principales productos, actividades y recursos
requeridos por el proyecto. Proporciona una
baseline sobre la que se hace un seguimiento
del progreso del proyecto fase por fase
■■ Controles del proyecto: resume los controles
a nivel de proyecto, incluyendo los límites de
fase, las tolerancias acordadas, el seguimiento y
la preparación de informes)
■■ Adaptación de PRINCE2: resumen de cómo
PRINCE2 podría adaptarse para el proyecto.
A.6.3 Derivación
■■ Expediente del Proyecto
■■ Conversaciones con partes interesadas (usuario,
organización y proveedor) para obtener su
opinión sobre métodos, normas y controles.
A.6.4 Formato y presentación
La Documentación de Inicio del Proyecto podría ser:
■■ Un único documento
■■ Un índice que remite a una colección de
documentos
■■ Un documento con referencias numéricas a
otros documentos
■■ Un conjunto de datos de una herramienta de
gestión de proyectos.
A.6.5 Criterios de calidad
■■ La Documentación de Inicio del Proyecto refleja
el proyecto correctamente
■■ Muestra un proyecto viable y factible, en línea
con la estrategia corporativa o las necesidades
generales del programa
■■ La estructura del equipo de gestión del
proyecto está completa, con nombres y cargos.
Se han tomado en consideración todos los
roles y están respaldados por las descripciones
de los roles convenidas. Las relaciones y líneas
de autoridad están claras. Si es necesario, la
estructura del equipo de gestión del proyecto
indica a quién rinde cuentas la Junta de
Proyecto
■■ Muestra claramente un régimen de control,
información y dirección que se puede aplicar y
es apropiado teniendo en cuenta el tamaño del
proyecto, su riesgo y la importancia que tiene
el proyecto para la gerencia corporativa o del
programa
■■ Los controles cubren las necesidades de la Junta
de Proyecto, el Project Manager y los Team
Managers y cumplen todos los requisitos de
garantía delegados
■■ Está claro quién aplicará cada control
■■ Los objetivos del proyecto, el enfoque y las
estrategias son coherentes con la normativa
de responsabilidad social corporativa de la
organización y los controles del proyecto son
los adecuados para asegurar que el proyecto
siga cumpliendo dicha normativa
■■ Se ha reflexionado sobre el formato de
la Documentación de Inicio del Proyecto.
Para proyectos pequeños es adecuado un
documento único. Para proyectos grandes es
más apropiado que la Documentación de Inicio
del Proyecto sea un conjunto de documentos
independientes. La estabilidad o inestabilidad
de cada elemento de la Documentación de
270 | Apéndice A: Contenido básico de las Descripciones de Productos
Inicio del Proyecto deberá tenerse en cuenta
para decidir si debería ir por separado; por
ejemplo, es mejor que los elementos que
probablemente vayan a cambiar con frecuencia
se guarden separadamente.
A.7 Estrategia de Gestión de la
Calidad
A.7.1 Propósito
Una Estrategia de Gestión de la Calidad se utiliza
para definir las técnicas y normas de calidad que se
deben aplicar durante el proyecto y las diferentes
responsabilidades para alcanzar los niveles de
calidad necesarios.
A.7.2 Composición
■■ Introducción: indica el propósito, los objetivos,
el alcance y quién es responsable de la
estrategia
■■ Procedimiento de gestión de calidad: una
descripción del procedimiento de gestión de
calidad que se debe utilizar o una referencia
al mismo. Se deberá poner de manifiesto
cualquier variación de las normas de calidad de
la gerencia corporativa o del programa, junto
a una justificación de la variación. El proceso
debería abarcar:
●● Planificación de calidad
●● Control de calidad: el enfoque del proyecto
en cuanto a las actividades de control de
calidad. Esto puede incluir:
●● Normas de Calidad
●● Modelos y formularios que se deban
emplear (por ejemplo, Descripciones de
Productos o Registro de Calidad)
●● Definiciones de tipos de métodos de
calidad (por ejemplo, inspección o
producto piloto) ■■
●● Sistemas de medición que se deben
emplear para facilitar el control de
calidad.
●● Garantía de calidad: el enfoque del proyecto
en cuanto a las actividades de garantía de
calidad. Esto puede incluir:
●● Responsabilidades de la Junta de Proyecto
●● Auditorías de cumplimiento
●● Revisiones por parte de la gerencia
corporativa o del programa
■■ Herramientas y técnicas: se refiere a todas las
herramientas o sistemas de gestión de calidad
que se van a utilizar y a cualquier preferencia
por las técnicas que se pueden utilizar en cada
paso del procedimiento de gestión de calidad
■■ Fichas: definición de las fichas de calidad
que serán necesarias y dónde se conservarán,
incluyendo la composición y formato del
Registro de Calidad
■■ Informes: describe los informes de gestión de
calidad que se deben preparar, su propósito,
calendario de elaboración y destinatarios
■■ Calendario de las actividades de gestión de
calidad: indica cuándo se deben realizar las
actividades formales de gestión de calidad,
como por ejemplo las auditorías (esto puede
consistir en una remisión al Registro de Calidad)
■■ Roles y responsabilidades: define los roles y las
responsabilidades en lo relativo a las actividades
de gestión de calidad, incluyendo cualquier
rol dentro de la gerencia corporativa o del
programa que tenga responsabilidades sobre la
calidad.
A.7.3 Derivación
■■ Junta de Proyecto
■■ Expediente del Proyecto
●● Estructura del equipo de gestión del
proyecto (para comprobar los roles y las
responsabilidades)
●● Descripción del Producto del Proyecto (para
comprobar las expectativas de calidad del
cliente y los criterios de aceptación)
■■ Normas organizativas
■■ Sistemas de gestión de calidad del proveedor y
del cliente
■■ Requisitos de la gestión de la configuración
■■ Requisitos del control de cambios
Estrategias corporativas o del programa
■■ Talleres de trabajo y discusiones informales
facilitadas.
A.7.4 Formato y presentación
Una Estrategia de Gestión de la Calidad puede
tener varios formatos, incluyendo:
■■ Un producto independiente o una sección de la
Documentación de Inicio del Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
 Apéndice A: Contenido básico de las Descripciones de Productos | 271
A.7.5 Criterios de calidad
■■ La estrategia define claramente los modos en
que se cumplirán las expectativas de calidad del
cliente
■■ Esos modos definidos son suficientes para
obtener la calidad necesaria
■■ Se han definido las responsabilidades de calidad
a un nivel que es independiente del proyecto y
del Project Manager
■■ La estrategia se ajusta a los sistemas de gestión
de calidad del proveedor y del cliente
■■ La estrategia se ajusta a la política de calidad
corporativa o del programa
■■ Los distintos enfoques para garantizar la
calidad del proyecto son adecuados a las
normas escogidas.
A.8 Estrategia de Gestión de la
Comunicación
A.8.1 Propósito
Una Estrategia de Gestión de la Comunicación
contiene una descripción de los medios y la
frecuencia de las comunicaciones a personas tanto
internas como externas al proyecto. Facilita la
comunicación con las partes interesadas mediante
el establecimiento de un flujo de información
controlado y bidireccional.
A.8.2 Composición
■■ Introducción: indica el propósito, los objetivos y
el alcance, e identifica quién es responsable de
la estrategia
■■ Procedimiento de comunicación: descripción
de los métodos de comunicación que se deben
utilizar o una referencia a los mismos. Se
deberá poner de manifiesto cualquier variación
de las normas de la gerencia corporativa o
del programa, junto a una justificación de la
variación
■■ Herramientas y técnicas: se refiere a todas las
herramientas de comunicación que se van a
utilizar y a cualquier preferencia por las técnicas
que se pueden utilizar en cada paso del proceso
de comunicación
■■ Fichas: definición de qué fichas de
comunicación serán necesarias y dónde se
conservarán (por ejemplo, la forma de llevar un
registro de la correspondencia externa)
■■ Informes: describe los informes sobre los
procesos de comunicación que se deben
elaborar, incluyendo su propósito, calendario
de elaboración y destinatarios (por ejemplo,
indicadores de rendimiento)
■■ Calendario de las actividades de comunicación:
indica cuándo se deben realizar actividades
de comunicación formal (por ejemplo, al
final de una fase), incluyendo auditorías del
rendimiento de los métodos de comunicación
■■ Roles y responsabilidades: describe quiénes
serán los responsables de cada aspecto del
proceso de comunicación, incluyendo cualquier
rol dentro de la gerencia corporativa o del
programa que tenga funciones en el ámbito de
la comunicación
■■ Análisis de las partes interesadas:
●● Identificación de las partes interesadas
(que por ejemplo puede incluir, el personal
de contabilidad, el foro de usuarios, los
auditores internos, los encargados de la
garantía de calidad a nivel corporativo o de
programa, la competencia, etc.)
●● Relación actual
●● Relación a la que se aspira
●● Interacciones
●● Mensajes principales
■■ Necesidades de información para cada parte
interesada:
●● Información que se debe proporcionar desde
el proyecto
●● Información que se debe proporcionar al
proyecto
●● Emisor y destinatario de la información
●● Frecuencia de la comunicación
●● Medio de comunicación
●● Formato de la comunicación.
A.8.3 Derivación
■■ Políticas de comunicación corporativa (por
ejemplo, normas sobre las obligaciones de
revelar información que afectan a las empresas
que cotizan en bolsa)
■■ Estrategia de gestión de la información del
programa
■■ Otros elementos de la Documentación de Inicio del
Proyecto (en concreto, la estructura del equipo de
gestión del proyecto, la Estrategia de Gestión del
Riesgo, la Estrategia de Gestión de la Calidad y la
Estrategia de Gestión de la Configuración)
272 | Apéndice A: Contenido básico de las Descripciones de Productos
■■ Talleres de trabajo o discusiones informales
facilitadas con las partes interesadas
■■ Análisis de las partes interesadas.
A.8.4 Formato y presentación
Una Estrategia de Gestión de la Comunicación
puede tener varios formatos, incluyendo:
■■ Un producto independiente o una sección de la
Documentación de Inicio del Proyecto
■■ Documento, hoja de cálculo o diagrama
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.8.5 Criterios de calidad
■■ Se ha identificado a todas las partes interesadas
y se les ha consultado sus necesidades de
comunicación
■■ Existe acuerdo con todas las partes interesadas
sobre el contenido, frecuencia y método de las
comunicaciones
■■ Se ha considerado un conjunto de normas
común para las comunicaciones
■■ Se ha tenido en cuenta en los Planes de Fase
el tiempo, esfuerzo y recursos necesarios para
llevar a cabo las comunicaciones identificadas
■■ La formalidad y la frecuencia de las
comunicaciones es razonable teniendo en
cuenta la importancia y complejidad del
proyecto
■■ Para proyectos que formen parte de un
programa, los canales de comunicación y la
estructura de presentación de informes entre
el proyecto y el programa se han reflejado
claramente en la Estrategia de Gestión de la
Comunicación
■■ La Estrategia de Gestión de la Comunicación
incluye, si resulta pertinente, servicios de
comunicación corporativa (por ejemplo,
utilizar el departamento de comunicaciones
de marketing para distribuir boletines del
proyecto).
A.9 Estrategia de Gestión de la
Configuración
A.9.1 Propósito
Una Estrategia de Gestión de la Configuración
se utiliza para identificar cómo y por quién se
controlarán y protegerán los productos del proyecto.
Responde a las siguientes preguntas:
■■ Cómo y dónde se almacenarán los productos del
proyecto
■■ Qué medidas de seguridad se adoptarán para el
almacenamiento y acceso
■■ Cómo se identificarán los productos y sus
diferentes versiones y variantes
■■ Cómo se controlarán los cambios en los
productos
■■ Dónde reside la responsabilidad de la gestión de
la configuración.
A.9.2 Composición
■■ Introducción: indica el propósito, los objetivos,
el alcance y quién es responsable de la
estrategia
■■ Procedimiento de gestión de la configuración:
una descripción del procedimiento de gestión
de la configuración que se debe utilizar o
una referencia al mismo. Se deberá poner de
manifiesto cualquier variación de las normas
de la gerencia corporativa o del programa,
junto a una justificación de la variación. El
procedimiento debería abarcar actividades
como planificación, identificación, control
(incluyendo almacenamiento/acceso, seguridad
de los productos, procedimientos de entrega,
etc.), informes sobre el estado de los productos
y verificación y auditoría
■■ Procedimiento de control de cambios
y cuestiones: una descripción de los
procedimientos de control de cambios y
cuestiones que se deben utilizar o una
referencia a los mismos. Se deberá poner de
manifiesto cualquier variación de las normas
de la gerencia corporativa o del programa,
junto a una justificación de la variación. El
procedimiento debería abarcar actividades
como: registrar, examinar, proponer, decidir e
implementar
■■ Herramientas y técnicas: se refiere a todas
las herramientas o sistemas de gestión de la
configuración que se van a utilizar y a cualquier
preferencia por las técnicas que se pueden
utilizar en cada paso del procedimiento de
gestión de la configuración
■■ Fichas: definición de la composición y formato
del Registro de Cuestiones y las Fichas de
Elementos de Configuración
 Apéndice A: Contenido básico de las Descripciones de Productos | 273
■■ Informes: describe la composición y formato de
los informes que se deben elaborar (Informe
de Cuestiones, Informe sobre el Estado de
los Productos), su propósito, su calendario de
producción y los destinatarios seleccionados. Se
debe incluir la revisión del rendimiento de los
procedimientos
■■ Calendario de las actividades de gestión de
la configuración y de control de cambios y
cuestiones: indica cuándo se deben realizar
actividades formales, como por ejemplo
auditorías de la configuración
■■ Roles y responsabilidades: describe quiénes
serán los responsables de cada aspecto de los
procedimientos, incluyendo cualquier rol dentro
de la gerencia corporativa o del programa que
tenga funciones en el ámbito de la gestión de
la configuración de los productos del proyecto.
Describe si se establecerá una Autoridad de
Cambios y/o un presupuesto para cambios
■■ Escalas de prioridad y severidad: para
priorizar las solicitudes de cambio y fuera de
especificación y para determinar el nivel de
gestión que puede tomar decisiones sobre la
severidad de las cuestiones.
A.9.3 Derivación
■■ Expectativas de calidad del cliente
■■ Sistema corporativo de gestión de la
configuración (por ejemplo, cualquier software
de gestión de la configuración en uso o
determinado por el usuario)
■■ Estrategia de Gestión de la Calidad del
Programa y estrategia de gestión de la
información del programa (si procede)
■■ Sistema de gestión de calidad del usuario
■■ Sistema de gestión de calidad del proveedor
■■ Necesidades específicas de los productos y
entorno del proyecto
■■ Estructura del equipo de gestión del
proyecto (para identificar a quienes tienen
responsabilidades sobre la gestión de la
configuración)
■■ Talleres de trabajo y discusiones informales
facilitadas.
A.9.4 Formato y Presentación
Una Estrategia de Gestión de la Configuración
puede tener varios formatos, incluyendo:
■■ Un producto independiente o una sección de la
Documentación de Inicio del Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.9.5 Criterios de calidad
■■ Las responsabilidades están claras y las han
entendido tanto el usuario como el proveedor
■■ Se ha definido el identificador principal de los
productos del proyecto
■■ El método y las circunstancias de control de las
versiones están claros
■■ La estrategia proporciona al Project Manager
toda la información necesaria sobre los
productos
■■ Se ha tenido en cuenta la estrategia corporativa
o del programa para la gestión de la
configuración
■■ El sistema de acceso proporcionará toda la
información necesaria de modo preciso, útil y
sin demora
■■ Los archivos del proyecto proporcionan la
información necesaria para las exigencias de
auditoría
■■ Los archivos del proyecto proporcionan los
datos históricos necesarios para respaldar
cualquier lección
■■ La Estrategia de Gestión de la Configuración
escogida es adecuada teniendo en cuenta el
tamaño y la naturaleza del proyecto
■■ Existen recursos para la aplicación del método
de gestión de la configuración escogido
■■ Las exigencias del grupo operativo (o cualquier
grupo similar a quien se deba transferir el
producto del proyecto) deben ser tenidas en
cuenta.
A.10 Estrategia de Gestión del
Riesgo
A.10.1 Propósito
La Estrategia de Gestión del Riesgo describe
las técnicas y normas específicas de gestión
del riesgo que se deben aplicar, así como las
responsabilidades en cuanto al desarrollo de un
procedimiento eficaz de gestión del riesgo.
A.10.2 Composición
■■ Introducción: indica el propósito, los objetivos,
el alcance y quién es responsable de la
estrategia
274 | Apéndice A: Contenido básico de las Descripciones de Productos
■■ Procedimiento de gestión del riesgo: una
descripción del procedimiento de gestión del
riesgo que se debe utilizar, o una referencia
al mismo. Se deberá poner de manifiesto
cualquier variación de las normas de la gerencia
corporativa o del programa, junto a una
justificación de la variación. El procedimiento
debería abarcar actividades como:
●● Identificar
●● Evaluar
●● Planificar
●● Implementar
●● Comunicar
■■ Herramientas y técnicas: se refiere a todas las
herramientas o sistemas de gestión del riesgo
que se van a utilizar y a cualquier preferencia
por las técnicas que se pueden utilizar en cada
paso del procedimiento de gestión del riesgo
■■ Fichas: definición de la composición y formato
del Registro de Riesgos y cualquier otra ficha de
riesgos utilizada para el proyecto
■■ Informes: describe los informes de gestión
de riesgo que se deben elaborar, incluyendo
su propósito, calendario de elaboración y
destinatarios
■■ Calendario de las actividades de gestión del
riesgo: indica cuándo se deben realizar las
actividades de gestión del riesgo. Por ejemplo,
durante las evaluaciones al final de fase
■■ Roles y responsabilidades: define los roles y las
responsabilidades en lo relativo a las actividades
de gestión del riesgo
■■ Escalas: define las escalas para estimar la
probabilidad y el impacto del proyecto a fin de
garantizar que las escalas de coste y de tiempo
(por ejemplo) sean pertinentes respecto al coste
y los plazos del proyecto. Estas escalas pueden
mostrarse en forma de tabla con probabilidades
de impactos, lo que proporciona criterios para
cada nivel dentro de la escala, es decir “muy
alta”, “alta”, “media”, “baja” y “muy baja”
■■ Proximidad: orientación sobre cómo evaluar
la proximidad de los acontecimientos que
concretarían el riesgo. La proximidad refleja
el hecho de que los riesgos tendrán lugar
en momentos concretos y la severidad de
su impacto variará dependiendo de cuándo
ocurran. Las categorías de proximidad más
habituales serán: inminente, durante la fase,
durante el proyecto, después del proyecto
■■ Categorías del riesgo: definición de las
categorías del riesgo que se van a utilizar
(si procede). Estas pueden derivarse de una
estructura jerárquica de riesgos o una lista de
posibles riesgos. Si no se ha incluido ningún
riesgo en una categoría concreta, puede ser un
indicio de que la identificación de riesgos no
fue tan exhaustiva como debía
■■ Categorías de respuesta al riesgo: definición de
las categorías de respuesta al riesgo que deben
utilizarse, las cuales dependen de si un riesgo
se percibe como una amenaza o como una
oportunidad
■■ Indicadores de preaviso: definición de todos los
indicadores que deben utilizarse para hacer un
seguimiento de los aspectos más importantes
del proyecto, de modo que si se alcanzan
ciertos niveles prefijados, se activarán las
rectificaciones. Serán seleccionados de acuerdo
con su relevancia respecto a los objetivos del
proyecto
■■ Tolerancia de riesgo: define los niveles de los
umbrales de exposición al riesgo que, cuando
se exceden, requieren que se presente una
excepción al siguiente nivel de gestión (por
ejemplo, podría fijarse una tolerancia de
riesgo a nivel de proyecto en el sentido de
que cualquier riesgo que ocurra ocasionaría
pérdidas comerciales. Dichos riesgos deberían
plantearse a la gerencia corporativa o del
programa). La tolerancia de riesgo debe
definir las expectativas de riesgo de la gerencia
corporativa o del programa y de la Junta de
Proyecto
■■ Presupuesto para riesgos: describe si se debe
establecer un presupuesto para riesgos y, en tal
caso, cómo se utilizará.
A.10.3 Derivación
■■ Expediente del Proyecto
■■ Business Case
■■ Guía o Estrategia de gestión del riesgo de la
gerencia corporativa o del programa.
A.10.4 Formato y presentación
Una Estrategia de Gestión del Riesgo puede tener
varios formatos, incluyendo:
■■ Un producto independiente o una sección de la
Documentación de Inicio del Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
 Apéndice A: Contenido básico de las Descripciones de Productos | 275
A.10.5 Criterios de calidad
■■ Las responsabilidades están claras y las han
entendido tanto el cliente como el proveedor
■■ El proceso de la gestión del riesgo se ha
documentado claramente y lo entienden todas
las partes
■■ Las escalas, el valor esperado y las definiciones
de proximidad se han indicado con claridad y
sin ambigüedad
■■ Las escalas escogidas son adecuadas teniendo
en cuenta el nivel de control necesario
■■ Las exigencias de comunicación de riesgos se
han definido completamente.
A.11 Expediente del Proyecto
A.11.1 Propósito
Un Expediente del Proyecto sirve para proporcionar
una base sólida y completa para el inicio del
proyecto y se crea en el proceso de la Puesta en
Marcha de un Proyecto.
En el proceso del Inicio de un Proyecto, el
contenido del Expediente del Proyecto se amplía y
mejora en la Documentación de Inicio del Proyecto
y a partir ahí ya no se mantiene el Expediente del
Proyecto.
A.11.2 Composición
■■ Definición del proyecto: explica aquello que el
proyecto tiene que conseguir. Debe incluir:
●● Antecedentes
●● Objetivos del proyecto (incluyendo objetivos
de tiempo, coste, calidad, alcance, riesgo y
beneficio)
●● Resultado deseado
●● Alcance del proyecto y exclusiones
●● Restricciones y suposiciones
●● Tolerancias del proyecto
●● El usuario o usuarios y cualquier parte
interesada conocida
●● Interacciones
■■ Business Case Preliminar (véase la sección A.3):
razones por las que se necesita el proyecto y
opción comercial escogida. Esto se desarrollará
posteriormente para crear un Business Case
detallado durante el proceso del Inicio de un
Proyecto
■■ Descripción del Producto del Proyecto (véase la
sección A.5): incluyendo expectativas de calidad
del cliente, criterios de aceptación del usuario y
criterios de aceptación de uso y mantenimiento
■■ Enfoque del proyecto: define la solución
escogida que se utilizará en el proyecto para
desarrollar la opción comercial del Business
Case elegida, teniendo en cuenta el entorno
operativo al que debe ajustarse la solución
■■ Estructura del equipo de gestión del proyecto:
un gráfico que muestra quién participa en el
proyecto
■■ Descripción de los roles: para el equipo de
gestión del proyecto y cualquier otro recurso
principal identificado en este momento
■■ Referencias: a cualquier documento o producto
asociado.
A.11.3 Derivación
■■ Un mandato de proyecto proporcionado al
comienzo del proyecto
■■ Gerencia del programa - si el proyecto
forma parte de un programa, el programa
proporcionará normalmente el Expediente del
Proyecto y, por lo tanto, no tendrá que derivar
de un mandato de proyecto
■■ Conversaciones con la gerencia corporativa
sobre la estrategia corporativa y cualquier
política o normas que resulten de aplicación
■■ Conversaciones con la Junta de Proyecto y
los usuarios si el mandato de proyecto está
incompleto o si no se ha proporcionado un
mandato de proyecto
■■ Conversaciones con la organización de uso y
mantenimiento (si procede)
■■ Conversaciones con los (posibles) proveedores
sobre ciclos de vida del desarrollo especializados
que podrían utilizarse
■■ Archivo sobre las Lecciones.
A.11.4 Formato y presentación
Un Expediente del Proyecto puede tener varios
formatos, incluyendo:
■■ Documento o presentación de diapositivas
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.11.5 Criterios de calidad
■■ Es breve porque su propósito en este momento
es proporcionar una base sólida sobre la
que iniciar un proyecto. Más adelante se
276 | Apéndice A: Contenido básico de las Descripciones de Productos
desarrollará y ampliará como parte de la
Documentación de Inicio del Proyecto
■■ El Expediente del Proyecto refleja con precisión
el mandato de proyecto y los requisitos
comerciales y de los usuarios
■■ El enfoque del proyecto toma en consideración
varias soluciones, como por ejemplo: creado
a medida o en serie, subcontratado o
desarrollado internamente, diseño nuevo o
modificación de un producto existente
■■ El enfoque del proyecto seleccionado maximiza
las posibilidades de éxito general del proyecto
■■ Los objetivos del proyecto, el enfoque del
proyecto y las estrategias son coherentes con la
normativa de responsabilidad social corporativa
de la organización
■■ Los objetivos del proyecto son eSpecíficos,
Medibles, Alcanzables, Realistas y cuentan con
una planificación Temporal (SMART).
A.12 Ficha de UN Elemento de
Configuración
A.12.1 Propósito
Proporcionar una ficha con información sobre el
historial, el estado, la versión y la variante de cada
elemento de configuración y cualquier detalle
de las relaciones importantes entre elementos de
configuración.
El conjunto de Fichas de Elementos de
Configuración de un proyecto se denomina
normalmente biblioteca de configuración.
A.12.2 Composición
La composición de una Ficha de un Elemento
de Configuración se definirá en la Estrategia de
Gestión de la Configuración del proyecto.
La siguiente lista contiene datos que se sugieren
para cada Ficha de un Elemento de Configuración
(téngase en cuenta que los tres primeros datos
identifican el elemento de configuración de forma
única).
■■ Identificador del proyecto: una referencia única.
Consistirá normalmente en un valor numérico o
alfanumérico
■■ Identificador del elemento: una referencia
única. Consistirá normalmente en un valor
numérico o alfanumérico
■■ Versión actual: normalmente un valor
alfanumérico
■■ Título del elemento: la descripción del elemento
(para un producto, esta debe coincidir con
la que conste en la estructura jerárquica de
productos)
■■ Fecha del último cambio de estado
■■ Propietario: la persona o grupo que tendrá la
propiedad del producto cuando el mismo sea
entregado
■■ Lugar: dónde se conserva el elemento
■■ Poseedores de copia (si procede): ¿quiénes
tienen actualmente el producto?
■■ Tipo de elemento: componente, producto,
release (véase la sección 9.2.2)
■■ Atributos del Elemento tal y como se definen
en la Estrategia de Gestión de la Configuración.
Se utilizan para especificar un subconjunto de
productos cuando se elabora el Informe sobre
el Estado de los Productos, como por ejemplo
la fase de gestión en la que se crea el producto,
el tipo de producto (por ejemplo, hardware o
software), el destino del producto, etc.
■■ Fase: fase en la que se desarrollará el producto
■■ Usuarios: la persona o grupo que utilizará el
elemento
■■ Estado: tal y como se define en la Estrategia
de Gestión de la Configuración, por ejemplo,
pendiente de desarrollo, en fase de desarrollo,
en fase de revisión, aprobado o entregado.
■■ Estado del elemento (si procede): tal y como
se define en la Descripción de Producto, por
ejemplo, maquinaria desmontada, maquinaria
desplazada, maquinaria reensamblada (véase la
sección 7.3.3.2)
■■ Variante (si procede): por ejemplo, variantes de
idioma
■■ Productor: la persona o equipo responsable de
crear u obtener el elemento
■■ Fecha asignada: al productor
■■ Fuente: por ejemplo, interna o adquirida de
una empresa externa
■■ Relación con otros elementos: aquellos
elementos que:
●● se verían afectados si este elemento
cambiase
●● si cambiasen, este elemento se vería
afectado
 Apéndice A: Contenido básico de las Descripciones de Productos | 277
■■ Referencias:
●● Cuestiones y riesgos
●● Documentación que define los requisitos,
diseño, estructura, producción y
verificación para el elemento (esto incluirá
específicamente la Descripción de Producto).
A.12.3 Derivación
■■ Estrategia de Gestión de la Configuración
■■ Estructura jerárquica de productos
■■ Plan de la Fase y Paquete de Trabajo
■■ Registro de Calidad, Registro de Cuestiones,
Registro de Riesgos.
A.12.4 Formato y presentación
Las Fichas de Elementos de Configuración pueden
tener varios formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Datos introducidos en una herramienta de
gestión de proyectos.
Las Fichas de Elementos de Configuración pueden
formar parte de una Base de Datos de Gestión de
la Configuración en el caso de las organizaciones
que tengan un sistema de gestión de la
configuración corporativo o de programa.
A.12.5 Criterios de calidad
■■ Las fichas reflejan el estado de los productos
con precisión
■■ Las fichas se guardan juntas en un lugar seguro
■■ Los números de versión se corresponden con los
productos a los que hacen referencia
■■ Las Fichas de Elementos de Configuración
muestran el historial de versiones de los
productos
■■ Existe un proceso mediante el cual se definen
y actualizan las Fichas de Elementos de
Configuración.
A.13 Informe al Final de Fase
A.13.1 Propósito
Un Informe al Final de Fase sirve para proporcionar
un resumen del progreso hasta la fecha, la
situación general del proyecto e información
suficiente para poder solicitar que la Junta de
Proyecto decida cómo continuar con el proyecto.
La Junta de Proyecto utiliza la información del
Informe al Final de Fase junto con el Plan de la
Fase siguiente para decidir qué acción realizar
con el proyecto: por ejemplo, autorizar la fase
siguiente, modificar el alcance del proyecto o parar
el proyecto.
A.13.2 Composición
■■ Informe del Project Manager: resume el
rendimiento de la fase
■■ Revisión del Business Case: resume la validez
del Business Case del proyecto
●● Beneficios obtenidos hasta la fecha
●● Beneficios residuales esperados (para las
fases restantes y post-proyecto)
●● Beneficios netos esperados
●● Desviaciones respecto del Business Case
aprobado
●● Exposición a riesgos agregada
■■ Revisión de los objetivos del proyecto: revisión
del rendimiento que ha tenido el proyecto
en comparación con sus metas planificadas
y los niveles de tolerancia de tiempo, coste,
calidad, alcance, beneficios y riesgo. Revisión
de la eficacia de las estrategias y controles del
proyecto
■■ Revisión de los objetivos de la fase: revisión
del rendimiento de la fase específica en
comparación con sus metas planificadas y los
niveles de tolerancia de tiempo, coste, calidad,
alcance, beneficios y riesgo
■■ Revisión del rendimiento del equipo: con
particular énfasis en el reconocimiento del buen
rendimiento
■■ Revisión de los productos:
●● Fichas de calidad: listan las actividades de
calidad planificadas y completadas en la fase
●● Fichas de aprobación: indican los productos
que se ha planificado completar en la fase y
las aprobaciones que requieren
●● Fuera de especificación: indica los productos
que faltan y los que no reúnen los requisitos
originales, así como la confirmación de
cualquier concesión que se haya aprobado
●● Entrega por fases (si procede): confirmación
por parte del cliente de que las funciones
de uso y mantenimiento están listas para la
entrega
●● Resumen de las acciones a realizar
recomendadas (si procede): Solicitud a
la Junta de Proyecto de asesoramiento
sobre quién debería recibir cada acción
278 | Apéndice A: Contenido básico de las Descripciones de Productos
recomendada. Las acciones recomendadas se
refieren a trabajo no finalizado, cuestiones
y riesgos en curso y cualquier otra actividad
necesaria para que los productos pasen a su
siguiente fase
■■ Informe sobre las Lecciones (si procede)
(véase la sección A.20): una revisión de lo
que salió bien, lo que salió mal y cualquier
recomendación a ser considerada por la
gerencia corporativa/del programa
■■ Cuestiones y riesgos: Resumen de las cuestiones
y riesgos que afectan actualmente al proyecto
■■ Pronóstico: Pronóstico del Project Manager para
el proyecto y la siguiente fase en comparación
con las metas planificadas y las tolerancias de
tiempo, coste, calidad, alcance, beneficios y
riesgo.
Cuando el Informe al Final de Fase se esté
elaborando al final de la fase de inicio, no todo el
contenido anteriormente descrito tiene por qué
ser apropiado o necesario.
A.13.3 Derivación
■■ Plan de la Fase actual y situación real
■■ Plan de Proyecto
■■ Plan de Revisión de Beneficios
■■ Registro de Riesgos, Registro de Calidad y
Registro de Cuestiones
■■ Informe de Excepción (si procede)
■■ Informe sobre las Lecciones
■■ Paquetes de Trabajo completados/atrasados
■■ Business Case actualizado
A.13.4 Formato y presentación
Un Informe al Final de Fase puede tener varios
formatos, incluyendo:
■■ Presentación a la Junta de Proyecto (reunión en
persona o teleconferencia)
■■ Documento o correo electrónico enviado a la
Junta de Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.13.5 Criterios de calidad
■■ El informe muestra claramente el rendimiento
de la fase comparado con el plan
■■ Se describen todas las situaciones anormales y
su impacto
■■ Todos los roles de Garantía del Proyecto
designados están de acuerdo con el informe.
A.14 Informe al Final de Proyecto
A.14.1 Propósito
Un Informe al Final de Proyecto se utiliza durante
el cierre del proyecto para revisar el rendimiento
del proyecto en comparación con la versión de la
Documentación de Inicio del Proyecto utilizada
para autorizar el proyecto. También permite:
■■ Transmitir lecciones cuya aplicación podría ser
de utilidad para otros proyectos
■■ Informar sobre los datos del trabajo no
finalizado, riesgos en curso o posibles
modificaciones del producto al grupo encargado
de la futura asistencia para los productos del
proyecto durante su vida útil.
A.14.2 Composición
■■ Informe del Project Manager: resume el
rendimiento del proyecto
■■ Revisión del Business Case: resume la validez
del Business Case del proyecto
●● Beneficios obtenidos hasta la fecha
●● Beneficios residuales esperados (post-
proyecto)
●● Beneficios netos esperados
●● Desviaciones respecto del Business Case
aprobado
■■ Revisión de los objetivos del proyecto: revisión
del rendimiento que ha tenido el proyecto en
comparación con sus metas planificadas y sus
tolerancias de tiempo, coste, calidad, alcance,
beneficios y riesgo. Revisión de la eficacia de las
estrategias y controles del proyecto
■■ Revisión del rendimiento del equipo: con
particular énfasis en el reconocimiento del buen
rendimiento
■■ Revisión de los productos:
●● Fichas de calidad: listan las actividades de
calidad planificadas y completadas
●● Fichas de aprobación: listan los productos y
sus aprobaciones necesarias
●● Fuera de especificación: indica los
productos que faltan y los que no cumplen
los requisitos originales, así como la
confirmación de cualquier concesión que se
haya aprobado
●● Entrega del producto del proyecto:
confirmación (en forma de certificados de
aceptación) por parte del cliente de que las
 Apéndice A: Contenido básico de las Descripciones de Productos | 279
funciones de uso y mantenimiento están
listas para recibir el producto del proyecto
●● Resumen de acciones a realizar
recomendadas: Solicitud a la Junta de
Proyecto de asesoramiento sobre quién
debería recibir cada acción recomendada. Las
acciones recomendadas se refieren a trabajo
no finalizado, cuestiones y riesgos en curso y
cualquier otra actividad necesaria para que
los productos pasen a su siguiente fase
■■ Informe sobre las Lecciones (véase la sección
A.20): una revisión de lo que fue bien, lo
que fue mal y cualquier recomendación a ser
considerada por la gerencia corporativa o del
programa (y si el proyecto se cerró de modo
prematuro, se deben explicar las razones).
A.14.3 Derivación
■■ Documentación de Inicio del Proyecto
■■ Business Case
■■ Plan de Proyecto
■■ Plan de Revisión de Beneficios
■■ Registro de Cuestiones, Registro de Calidad y
Registro de Riesgos
■■ Informe sobre las Lecciones
■■ Informes al Final de Fase (e Informes de
Excepción, si procede).
A.14.4 Formato y presentación
Un Informe al Final de Proyecto puede tener varios
formatos, incluyendo:
■■ Presentación a la Junta de Proyecto (reunión en
persona o teleconferencia)
■■ Documento o correo electrónico enviado a la
Junta de Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.14.5 Criterios de calidad
■■ Se describen todas las situaciones anormales y
su impacto
■■ Al final del proyecto, todas las cuestiones deben
cerrarse o quedar sujetas a una acción a realizar
recomendada
■■ Las acciones a realizar recomendadas deberán
estar acompañadas de cualquier documentación
o prueba de utilidad que se halle disponible
■■ Todos los roles de Garantía del Proyecto
designados deberían estar de acuerdo con el
informe.
A.15 Informe de Cuestiones
A.15.1 Propósito
Un Informe de Cuestiones es un informe que
contiene la descripción, la evaluación del impacto y
las recomendaciones para una solicitud de cambio,
fuera de especificación o un problema/asunto. Sólo
se crea para aquellas cuestiones que es necesario
manejar formalmente.
El informe se crea inicialmente cuando se registra
una cuestión y se actualiza tanto cuando se ha
examinado la cuestión así como cuando se han
identificado propuestas para la resolución de la
cuestión. El Informe de Cuestiones se modifica de
nuevo para reflejar la decisión sobre la opción que
se va a implementar y se actualiza por última vez
cuando la implementación se ha verificado y la
cuestión se ha cerrado.
A.15.2 Composición
■■ Identificador de la cuestión: véase lo indicado
para el Registro de Cuestiones (proporciona
una referencia única para cada Informe de
Cuestiones)
■■ Tipo de cuestión: define el tipo de cuestión que
se anota, concretamente:
●● Solicitud de cambio
●● Fuera de especificación
●● Problema/asunto
■■ Fecha de presentación la fecha en la que se
planteó inicialmente la cuestión
■■ Presentada por: el nombre de la persona o
equipo que planteó la cuestión
■■ Autor del Informe de Cuestiones: el nombre de
la persona o equipo que elaboró el Informe de
Cuestiones
■■ Descripción de la cuestión: explicación en la que
se describe la cuestión, su causa y su impacto
■■ Análisis del impacto: un análisis detallado del
probable impacto de la cuestión. Puede incluir,
por ejemplo, una lista de los productos sobre
los que exista algún impacto
■■ Recomendación: una descripción de lo que el
Project Manager cree que se debe hacer para
resolver la cuestión (y por qué)
■■ Prioridad: se debe especificar remitiéndose a
la escala escogida para el proyecto. Se debe
revaluar tras el análisis del impacto
■■ Severidad: se debe especificar remitiéndose a la
escala escogida para el proyecto. La severidad
280 | Apéndice A: Contenido básico de las Descripciones de Productos
indicará qué nivel de gestión debe tomar una
decisión sobre la cuestión
■■ Decisión: la decisión tomada (aceptar, rechazar,
postergar u otorgar una concesión)
■■ Aprobado por: una indicación de quién tomó la
decisión
■■ Fecha de la decisión: la fecha de la decisión
■■ Fecha de cierre: la fecha en que se cerró la
cuestión.
A.15.3 Derivación
■■ El formato y la composición del Informe de
Cuestiones se definirán en la Estrategia de
Gestión de la Configuración
■■ Informe(s) de Desarrollo, Informe(s) del Punto
de Control e Informe(s) al Final de Fase
■■ Plan de la Fase, junto con datos de los valores y
circunstancias reales
■■ Usuarios y equipos del proveedor o proveedores
que estén trabajando en el proyecto
■■ La aplicación de controles de calidad
■■ Observación y experiencia de los procesos
■■ Registro de Calidad, Registro de Riesgos y
Archivo sobre las Lecciones
■■ Paquetes de Trabajo completados.
A.15.4 Formato y presentación
Un Informe de Cuestiones puede tener varios
formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Datos introducidos en una herramienta de
gestión de proyectos
No todas las anotaciones del Registro de
Cuestiones tendrán que ser documentadas por
separado en un Informe de Cuestiones.
A.15.5 Criterios de Calidad
■■ La cuestión está indicada con claridad y sin
ambigüedad
■■ Ha tenido lugar un análisis detallado del
impacto
■■ Se han considerado todas las implicaciones
■■ Se ha examinado la cuestión desde el punto de
vista de su efecto sobre las tolerancias
■■ Se ha documentado correctamente la cuestión
en el Registro de Cuestiones
■■ Se describen las decisiones con precisión y sin
ambigüedad.
A.16 Informe de Desarrollo
A.16.1 Propósito
Un Informe de Desarrollo tiene la función
de proporcionar a la Junta de Proyecto (y
posiblemente a otras partes interesadas) un
resumen del estado de la fase, a intervalos
establecidos por la Junta. La Junta de Proyecto
utiliza el informe para realizar un seguimiento
del progreso de la fase y del proyecto. El Project
Manager también lo utiliza para informar a
la Junta de Proyecto sobre cualquier posible
problema o sobre aspectos del proyecto en los que
la Junta de Proyecto podría ayudar.
A.16.2 Composición
■■ Fecha: la fecha del informe
■■ Período: el período de informe cubierto por el
Informe de Desarrollo
■■ Resumen del estado: visión general del estado
de la fase en ese momento
■■ Este período de informe:
●● Paquetes de Trabajo – pendientes de
autorización, en ejecución y completados
en el período (si los Paquetes de Trabajo
están siendo desarrollados por proveedores
externos, esta información puede ir
acompañada de órdenes de compra y datos
de facturación)
●● Productos completados en el período
●● Productos planificados pero no
comenzados o completados en el período
(proporcionando un indicador de preaviso o
una advertencia de problemas potenciales
con la tolerancia de tiempo)
●● Rectificaciones realizadas durante el período
■■ Siguiente período de informe:
●● Paquetes de Trabajo – autorizados, en
ejecución y a completar durante el siguiente
período (si los Paquetes de Trabajo están
siendo desarrollados por proveedores
externos esta información puede ir
acompañada de órdenes de compra y datos
de facturación)
●● Productos que se deben completar en el
siguiente período
●● Rectificaciones que se deben completar en el
siguiente período
■■ Estado de la tolerancia del proyecto y la fase:
cómo se está desarrollando la ejecución del
 Apéndice A: Contenido básico de las Descripciones de Productos | 281
proyecto y la fase frente a sus tolerancias (por
ejemplo, costes/plazos reales y previstos)
■■ Solicitudes de cambio – planteadas, aprobadas/
rechazadas y pendientes
■■ Cuestiones y riesgos principales: resumen de
problemas y riesgos reales y potenciales
■■ Informe sobre las Lecciones (si procede)
(véase la sección A.20): una revisión de lo
que salió bien, lo que salió mal y cualquier
recomendación a ser considerada por la
gerencia corporativa o del programa.
A.16.3 Derivación
■■ Documentación de Inicio del Proyecto
■■ Informes del Punto de Control
■■ Registro de Cuestiones, Registro de Calidad y
Registro de Riesgos
■■ Plan de la Fase y situación real
■■ Estrategia de Gestión de la Comunicación.
A.16.4 Formato y presentación
Un Informe de Desarrollo puede tener varios
formatos, incluyendo: futuros.
■■ Presentación a la Junta de Proyecto (reunión en
persona o teleconferencia)
■■ Documento o correo electrónico enviado a la
Junta de Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.16.5 Criterios de calidad
■■ El nivel y la frecuencia de los informes sobre el
progreso requeridos por la Junta de Proyecto
son los adecuados para la fase y/o proyecto
■■ El Project Manager proporciona el Informe de
Desarrollo con la frecuencia y con el contenido
establecidos por la Junta de Proyecto
■■ La información es oportuna, útil, precisa y
objetiva
■■ El informe pone de relieve cualquier aspecto
que pueda plantear problemas.
A.17 Informe de Excepción
A.17.1 Propósito
Un Informe de Excepción se elabora cuando se
prevé que un Plan de la Fase o Plan de Proyecto
excederá los niveles de tolerancia establecidos.
Lo prepara el Project Manager para informar a la
Junta de Proyecto de la situación y ofrecer opciones
y recomendaciones sobre los pasos a seguir.
A.17.2 Composición
■■ Título de la excepción: visión general de la
excepción sobre la que se informa
■■ Causa de la excepción: descripción de la causa
de una desviación del plan actual
■■ Consecuencias de la desviación: cuáles serán
las consecuencias, si no se actúa frente a la
desviación, para:
●● El proyecto
●● La gerencia corporativa o del programa
■■ Opciones: cuáles son las opciones disponibles
para hacer frente a la desviación y cuál será el
efecto de cada opción sobre el Business Case,
los riesgos y las tolerancias
■■ Recomendación: qué se recomienda a la vista
de las distintas opciones disponibles y por qué
■■ Lecciones: Qué se puede aprender de la
excepción, para este proyecto o para proyectos
A.17.3 Derivación
■■ Plan actual y situación real
■■ Registro de Cuestiones, Registro de Riesgos y
Registro de Calidad
■■ Informes de Desarrollo (para desviaciones a
nivel de fase/proyecto) o Informes del Punto de
Control (para desviaciones a nivel de equipo)
■■ Información de la Junta de Proyecto sobre un
acontecimiento externo que puede afectar al
proyecto.
A.17.4 Formato y presentación
Un Informe de Excepción puede tener varios
formatos, incluyendo:
■■ Cuestión planteada en una sesión de revisión
del progreso en la que se levante acta (reunión
en persona o teleconferencia)
■■ Documento o correo electrónico enviado al
nivel de gestión inmediatamente superior
■■ Datos introducidos en una herramienta de
gestión de proyectos.
Para excepciones urgentes, se recomienda que
el Informe de Excepción tenga forma verbal
inicialmente y a continuación se refleje en el
formato acordado.
282 | Apéndice A: Contenido básico de las Descripciones de Productos
A.17.5 Criterios de calidad
■■ El plan actual debe mostrar con exactitud el
estado del rendimiento de los costes y del
tiempo
■■ Debe indicar la razón o razones de la
desviación, analizar claramente la excepción y
evaluar y describir completamente su posible
impacto
■■ Se han tenido en cuenta las implicaciones para
el Business Case y se ha calculado el impacto en
el Plan de Proyecto en general
■■ Se han analizado las opciones (incluyendo
los riesgos asociados a las mismas) y se han
realizado recomendaciones sobre la mejor
manera de proceder
■■ El Informe de Excepción se ha presentado de
modo apropiado y sin demora.
A.18 Informe del Punto de Control
A.18.1 Propósito
Un Informe del Punto de Control se utiliza para
informar del estado del Paquete de Trabajo, con la
frecuencia especificada en el Paquete de Trabajo.
A.18.2 Composición
■■ Fecha: la fecha del punto de control
■■ Período: el período cubierto por el Informe del
Punto de Control
■■ Seguimiento: a partir de informes anteriores,
por ejemplo acciones completadas o cuestiones
pendientes
■■ Este período de informe:
●● Los productos que el equipo está
desarrollando durante el período de informe
●● Los productos que el equipo ha completado
durante el período de informe
●● Actividades de gestión de calidad realizadas
durante el período
●● Lecciones que se hayan identificado
■■ Siguiente período de informe:
●● Los productos que el equipo va a desarrollar
durante el siguiente período de informe
●● Los productos que se planifica que el equipo
complete durante el siguiente período de
informe
●● Actividades de gestión de calidad
planificadas para el siguiente período de
informe
■■ Estado de la tolerancia del Paquete de Trabajo:
cómo se está desarrollando la ejecución del
Paquete de Trabajo frente a sus tolerancias (por
ejemplo, alcance/costes/plazos reales y previstos)
■■ Cuestiones y riesgos: puesta al día sobre las
cuestiones y riesgos asociados al Paquete de
Trabajo.
A.18.3 Derivación
■■ Paquete de Trabajo
■■ Plan del Equipo y situación real
■■ Informe del Punto de Control anterior.
A.18.4 Formato y Presentación
Un Informe del Punto de Control puede tener
varios formatos, incluyendo:
■■ Informe verbal al Project Manager (puede ser
en persona o por teléfono)
■■ Presentación en una sesión de revisión
del progreso (reunión en persona o
teleconferencia)
■■ Documento o correo electrónico enviado al
Project Manager
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.18.5 Criterios de calidad
■■ Preparado con la frecuencia exigida por el
Project Manager
■■ El nivel y la frecuencia de la evaluación del
progreso son los adecuados para la fase y/o
Paquete de Trabajo correspondiente
■■ La información es oportuna, útil, objetiva y
precisa
■■ El informe abarca todos los productos del
Paquete de Trabajo para ese período
■■ Se proporciona una actualización de todas las
cuestiones que constaban como no solucionadas
en el informe anterior.
A.19 Informe sobre el Estado de los
Productos
A.19.1 Propósito
El Informe sobre el Estado de los Productos
proporciona información sobre el estado de los
productos dentro de unos límites definidos. Estos
límites pueden variar. Por ejemplo, el informe
 Apéndice A: Contenido básico de las Descripciones de Productos | 283
puede incluir el proyecto entero, una fase en
particular, un área específica del proyecto o el
historial de un producto concreto. Resulta de
especial utilidad cuando el Project Manager desea
confirmar el número de versión de los productos.
A.19.2 Composición
■■ Alcance del Informe: describe el alcance del
informe (por ejemplo: para todo el proyecto,
por fase, por tipo de producto, por proveedor,
etc. El atributo del producto se puede utilizar
para seleccionar el subconjunto de productos
que se va a incluir en el informe)
■■ Fecha de elaboración: la fecha en que se
preparó el informe
■■ Estado del Producto: Para cada producto dentro
del alcance del informe, el informe puede
incluir:
●● Identificador y título del producto
●● Versión
●● Estado y fecha de cambio de estado
●● Condición del producto
●● Propietario
●● Poseedores de copia
●● Lugar
●● Usuario(s)
●● Productor y fecha asignada al productor
●● Fecha planificada y real de la versión
baseline de la Descripción de Producto
●● Fecha planificada y real de la versión
baseline del Producto
●● Fecha planificada de la siguiente versión
baseline
●● Lista de elementos relacionados
●● Lista de cuestiones relacionadas (incluyendo
cambios pendientes y aprobados) y riesgos
relacionados.
A.19.3 Derivación
■■ Fichas de Elementos de Configuración
■■ Plan de la Fase
A.19.4 Formato y presentación
Un Informe sobre el Estado de los Productos puede
tener varios formatos, incluyendo:
■■ Documento, hoja de cálculo o informe a partir
de una base de datos
■■ Datos obtenidos de una herramienta de gestión
de proyectos.
A.19.5 Criterios de calidad
■■ La información y las fechas se corresponden con
las indicadas en el Plan de la Fase
■■ El nombre del producto es coherente con
la estructura jerárquica de productos y el
nombre indicado en las Fichas de Elementos de
Configuración.
A.20 Informe sobre las Lecciones
A.20.1 Propósito
El Informe sobre las Lecciones se utiliza para
comunicar lecciones que se puedan aplicar, de
modo útil, a otros proyectos.
El propósito del informe es provocar acciones
para que las lecciones positivas queden integradas
en el modo de trabajar de la organización
(u organizaciones) y que la organización (u
organizaciones) sea capaz de evitar las lecciones
negativas en futuros proyectos.
Los Informes sobre las Lecciones pueden
elaborarse en cualquier etapa del proyecto y no
deben necesariamente esperar hasta el final.
Normalmente un Informe sobre las Lecciones
vendría incluido como parte del Informe al Final de
Fase y el Informe al Final de Proyecto. Podría ser
apropiado (y necesario) que existan varios Informes
sobre las Lecciones específicos para la organización
en particular (por ejemplo, usuario, proveedor,
corporativo/de programa).
La información incluida en el informe debe
ser utilizada por el grupo corporativo que sea
responsable del sistema de gestión de calidad,
para perfeccionar, cambiar y mejorar las normas.
Las estadísticas sobre la cantidad de esfuerzo que
fue necesario para cada producto pueden ayudar a
mejorar los cálculos futuros.
A.20.2 Composición
■■ Resumen ejecutivo
■■ Alcance del informe (por ejemplo, fase o
proyecto)
■■ Una revisión de lo que salió bien, lo que
salió mal y cualquier recomendación a ser
considerada por la gerencia corporativa o del
programa. En concreto:
●● Método de gestión del proyecto (incluyendo
la adaptación de PRINCE2)
284 | Apéndice A: Contenido básico de las Descripciones de Productos
Cualquier método especializado que se haya
●●
utilizado
●● Estrategias del Proyecto (gestión de
riesgo, gestión de calidad, gestión de la
comunicación y gestión de la configuración)
●● Controles del Proyecto (y la eficacia de
cualquier adaptación)
●● Acontecimientos anormales que causaron
desviaciones
■■ Una revisión de los cálculos útiles como:
●● cuánto esfuerzo fue necesario para crear los
productos
●● qué nivel de eficacia tuvo la Estrategia de
Gestión de la Calidad a la hora de diseñar,
desarrollar y completar productos que
desempeñen correctamente su función (por
ejemplo, ¿cuántos errores se detectaron
después de que los productos hubieran
pasado las inspecciones de calidad?)
●● estadísticas sobre cuestiones y riesgos
■■ Para las lecciones que sean importantes puede
ser útil proporcionar datos adicionales sobre:
●● Acontecimiento
●● Efecto (por ejemplo, impacto económico
positivo/negativo)
●● Causas/desencadenante
●● Si existía algún indicador de preaviso
●● Recomendaciones
●● Si el acontecimiento desencadenante se
había identificado anteriormente como
riesgo (amenaza u oportunidad).
A.20.3 Derivación
■■ Documentación de Inicio del Proyecto (para la
posición baseline)
■■ Archivo sobre las Lecciones (para identificar las
lecciones)
■■ Registro de Calidad, Registro de Cuestiones y
Registro de Riesgos (para análisis estadísticos)
■■ Fichas de calidad (para análisis estadísticos)
■■ Estrategia de Gestión de la Comunicación (para
la lista de distribución).
A.20.4 Formato y presentación
Un Informe sobre las Lecciones puede tener varios
formatos, incluyendo:
■■ Informe verbal a la Junta de Proyecto (puede
ser en persona o por teléfono)
■■ Presentación en una sesión de revisión
del progreso (reunión en persona o
teleconferencia)
■■ Documento o correo electrónico enviado a la
Junta de Proyecto
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.20.5 Criterios de calidad
■■ Se han examinado todos los controles de
gestión
■■ Se proporcionan estadísticas de las diferencias
entre las previsiones y la situación real
■■ Se incluyen estadísticas sobre el éxito de los
controles de calidad utilizados
■■ Todos los roles de Garantía del Proyecto
designados están de acuerdo con el informe
■■ Se revisan los riesgos inesperados para
determinar si se podrían haber previsto
■■ Se proporcionan acciones recomendadas
para cada lección (nota: las lecciones no son
“aprendidas” hasta que se realizan acciones).
A.21 Paquete de Trabajo
A.21.1 Propósito
Un Paquete de Trabajo es un conjunto de
información sobre uno o más productos necesarios
que el Project Manager recopila para transmitir
formalmente la responsabilidad de su entrega o de
las tareas relacionadas a un Team Manager o a un
miembro del equipo.
A.21.2 Composición
Aunque es posible que el contenido cambie en
gran medida según la relación entre el Project
Manager y la persona que lo reciba, el Paquete de
Trabajo deberá incluir:
■■ Fecha: la fecha del acuerdo entre el Project
Manager y el Team Manager o persona
autorizada
■■ Team Manager o persona autorizada: el
nombre del Team Manager o persona con quien
se realizó el acuerdo
■■ Descripción del Paquete de Trabajo: descripción
del trabajo a realizar
■■ Técnicas, procesos y procedimientos: todas
las técnicas, herramientas, normas, procesos y
procedimientos que deben ser utilizados en la
creación de productos especializados
 Apéndice A: Contenido básico de las Descripciones de Productos | 285
■■ Interacciones de desarrollo: se deben mantener
interacciones durante el desarrollo de los
productos. Pueden consistir en personas que
proporcionan información o personas que
necesitan recibirla
■■ Interacciones de uso y mantenimiento:
identificación de todos los productos
especializados con los que el producto o los
productos del Paquete de Trabajo necesitan
interactuar durante su vida útil. Puede tratarse
de otros productos creados por el proyecto,
productos ya existentes o aquéllos que crearán
otros proyectos (por ejemplo, si el proyecto es
parte de un programa)
■■ Exigencias de gestión de la configuración: una
indicación de los arreglos que debe realizar
el productor para: controlar las versiones de
los productos del Paquete de Trabajo, obtener
copias de otros productos o de sus Descripciones
de Productos, entregar el producto a la
gestión de la configuración, respetar cualquier
requisito de almacenamiento o seguridad y,
eventualmente, informar a quien corresponda
sobre cambios en el estado del Paquete de
Trabajo
■■ Acuerdos conjuntos: información sobre los
acuerdos conjuntos con respecto a esfuerzo,
coste, fechas de comienzo y finalización e hitos
principales del Paquete de Trabajo
■■ Tolerancias: información sobre las tolerancias
del Paquete de Trabajo (las tolerancias de
tiempo y coste, pero también podrán incluir
alcance y riesgo)
■■ Restricciones: todas las restricciones (excepto las
tolerancias) sobre tareas, participantes, fechas,
costes, normas a seguir (por ejemplo, relativas a
seguridad), etc.
■■ Detalles de los informes: la frecuencia y el
contenido esperados de los Informes del Punto
de Control
■■ Cómo abordar y presentar problemas: se refiere
al procedimiento para presentar cuestiones y
riesgos
■■ Extractos o referencias: todos los extractos o
referencias a documentos relacionados, y más
concretamente:
●● Extracto del Plan de la Fase: será la sección
relevante del Plan de la Fase de gestión
actual o bien una indicación al respecto
●● Descripciones de Productos: normalmente
tendrá la forma de un anexo con la
Descripción de Producto para cada producto
identificado en el Paquete de Trabajo
(téngase en cuenta que la Descripción de
Producto detalla los métodos de calidad a
utilizar)
■■ Método de aprobación: la persona, rol o grupo
que aprobará los productos completados del
Paquete de Trabajo y cómo se informará al
Project Manager de que se han finalizado los
productos y el Paquete de Trabajo.
Deberá existir espacio en el Paquete de Trabajo
para registrar tanto su autorización inicial como
su aceptación y entrega como Paquete de Trabajo
finalizado. Se podrá ampliar para que incluya
una evaluación del trabajo y se dirija hacia una
valoración del rendimiento.
Es posible que los proyectos con controles comunes
en todos los Paquetes de Trabajo se limiten a
remitir a los controles definidos en el Plan de
Proyecto o el Plan de la Fase.
A.21.3 Derivación
■■ Acuerdos comerciales en vigor entre el cliente y
el proveedor (si corresponde)
■■ Estrategia de Gestión de la Calidad
■■ Estrategia de Gestión de la Configuración
■■ Plan de la Fase.
A.21.4 Formato y presentación:
Un Paquete de Trabajo puede tener varios
formatos, incluyendo:
■■ Documento
■■ Conversación verbal entre el Project Manager y
un Team Manager
■■ Datos introducidos en una herramienta de
gestión de proyectos.
El contenido y nivel de formalidad del Paquete de
Trabajo variarán según las circunstancias.
Si el trabajo lo está realizando un equipo que
depende directamente del Project Manager, el
Paquete de Trabajo puede ser una instrucción
verbal, aunque existen buenas razones para
ponerlo por escrito como, por ejemplo, evitar que
surjan malentendidos o proporcionar una conexión
con el sistema de evaluación del rendimiento.
Si el trabajo lo está realizando un proveedor
con contrato y el Project Manager es parte de la
organización del cliente, existe la necesidad de una
instrucción formal por escrito que se ajuste a las
normas establecidas en el contrato.
286 | Apéndice A: Contenido básico de las Descripciones de Productos

A.21.5 Criterios de calidad utilizan como baseline para hacer el seguimiento

■■ El Paquete de Trabajo necesario está definido del progreso de la fase.
claramente y es entendido por el recurso Los Planes de Equipo (si se utilizan) podrían
designado consistir simplemente en un cronograma adjunto al
■■ Existe una Descripción de Producto para cada Paquete o Paquetes de Trabajo asignados al Team
producto requerido, con criterios de calidad Manager.
aceptables y claramente identificados Un plan no debe cubrir solamente las actividades
■■ Las Descripciones de Productos encajan con la para crear productos sino también las actividades
otra documentación del Paquete de Trabajo para gestionar la creación de productos, incluyendo
actividades de garantía, gestión de calidad,
■■ Se han acordado las normas de trabajo
gestión de riesgo, gestión de la configuración,
■■ Las normas definidas se ajustan a aquéllas
comunicación y cualquier otro control del proyecto
aplicadas a productos similares
que sea necesario.
■■ Se han definido todas las interacciones
necesarias A.22.2 Composición
■■ Los arreglos, con respecto a los informes,
■■ Descripción del plan: consiste en una breve
incluyen la posibilidad de que se necesite
descripción de lo que abarca el plan (por
plantear cuestiones y riesgos
ejemplo, proyecto, fase, equipo, excepción) y el
■■ Existe acuerdo entre el Project Manager y la enfoque del plan
persona que recibirá el Paquete de Trabajo
■■ Prerrequisitos del plan: incluye todos los
sobre qué se necesita llevar a cabo
aspectos fundamentales que deben existir y
■■ Existe acuerdo sobre las restricciones, seguir existiendo para que el plan tenga éxito
incluyendo el esfuerzo, coste y objetivos
■■ Dependencias externas: que puedan influir en
■■ Las fechas y el esfuerzo se ajustan a los el plan
previstos en el Plan de la Fase de getión actual.
■■ Suposiciones relacionadas con la planificación:
Se han definido los arreglos con respecto a los
en las que se basa el plan
informes
■■ Lecciones incorporadas: información sobre las
■■ Se han definido todos los requisitos sobre
lecciones pertinentes de proyectos anteriores
asistencia independiente y participación en las
similares que se han revisado y adaptado a este
actividades de calidad.
plan
■■ Seguimiento y control: información sobre cómo
A.22 Plan se controlará y se hará el seguimiento del plan
■■ Presupuestos: abarcan el tiempo y coste,
A.22.1 Propósito
incluyendo provisiones para riesgos y cambios
Un plan proporciona una explicación sobre cómo y
■■ Tolerancias: tiempo, coste y alcance de las
cuándo se deben cumplir los objetivos, mostrando
tolerancias para el nivel del plan (también
los principales productos, actividades y recursos
pueden incluir tolerancias de riesgo más
necesarios para el alcance del plan. En PRINCE2,
específicas a nivel de fase o equipo)
hay tres niveles de Plan: proyecto, fase y equipo.
■■ Descripciones de Productos (véase la sección
Los Planes de Equipo son opcionales y puede que
A.4): abarcan los productos cubiertos por el
no necesiten tener la misma composición que un
plan (para el Plan de Proyecto esto incluirá el
Plan de Proyecto o un Plan de la Fase.
producto del Proyecto, para el Plan de la Fase
Un Plan de Excepción se crea en el mismo nivel que
será los productos de la fase y para un plan del
el plan al que reemplaza.
equipo debería ser una referencia al Paquete de
Un Plan de Proyecto proporciona el Business Case Trabajo asignado). Las tolerancias de calidad se
con los costes planificados e identifica las fases de definirán en cada Descripción de Producto
gestión y otros puntos de control importantes. La
■■ Cronograma: que puede incluir
Junta de Proyecto lo utiliza como baseline para
representaciones gráficas de:
hacer el seguimiento del progreso del proyecto.
●● Diagrama de Gantt o de barras
Los Planes de Fase cubren los productos, recursos,
actividades y controles específicos de la fase y se
 Apéndice A: Contenido básico de las Descripciones de Productos | 287

●● Estructura jerárquica de productos (véase el ■■ Datos introducidos en una herramienta de

ejemplo del Apéndice D) gestión de proyectos.
●● Diagrama de flujo de los productos (véase el El cronograma puede incluirse en forma de lista
ejemplo del Apéndice D) de productos (que es una lista de los productos
●● Red de actividades que se deben entregar dentro del alcance del plan
●● Tabla de recursos necesarios – por tipos de junto a fechas de estado claves como “borrador
recurso (por ejemplo, 4 ingenieros, 1 director preparado”, “calidad inspeccionada”, “aprobado”,
de pruebas, 1 analista comercial) etc.) o de datos extraídos de una herramienta de
●● Tabla de recursos específicos solicitados/ planificación de proyectos.
asignados – con nombres (por ejemplo,
Nicolás, Javier, Francisca). A.22.5 Criterios de calidad
■■ El plan es factible
A.22.3 Derivación
■■ Las estimaciones se basan en consultas con los
■■ Expediente del Proyecto recursos que llevarán a cabo el trabajo y/o en
■■ Estrategia de Gestión de la Calidad (para datos históricos
las actividades de gestión de calidad que se ■■ Los Team Managers están de acuerdo en que su
incluirán en el plan) parte del plan es factible
■■ Estrategia de Gestión del Riesgo (para las ■■ Está planificado con una cantidad de
actividades de gestión del riesgo que se información apropiada (ni demasiada, ni
incluirán en el plan) demasiado poca)
■■ Estrategia de Gestión de la Comunicación (para ■■ El plan cumple con las normas corporativas o
las actividades de gestión de la comunicación del programa necesarias
que se incluirán en el plan) ■■ El plan incorpora lecciones de proyectos
■■ Estrategia de Gestión de la Configuración (para anteriores
las actividades de gestión de la configuración ■■ El plan cumple con los requisitos legales
que se incluirán en el plan)
aplicables
■■ Disponibilidad de recursos ■■ El plan abarca actividades de gestión y control
■■ Registros y archivos. (como por ejemplo, calidad) así como las
actividades para crear los productos previstos
A.22.4 Formato y presentación ■■ El plan secunda la Estrategia de Gestión
Un Plan puede tener varios formatos, incluyendo: de la Calidad, la Estrategia de Gestión de
■■ Un documento independiente o una sección de la Configuración, la Estrategia de Gestión
la Documentación de Inicio del Proyecto del Riesgo, la Estrategia de Gestión de la
■■ Documento, hoja de cálculo, presentación de
Comunicación y el enfoque del proyecto
diapositivas, diagramas o mapas conceptuales ■■ El plan apoya los controles de gestión definidos
en la Documentación de Inicio del Proyecto.
Tabla A1: Ejemplo de una lista de productos
Identificador del

Descripción Control final

Nombre del Entregado
producto

de Producto Borrador listo de calidad Aprobado

producto (si corresponde)
aprobada completado

Plan Real Plan Real Plan Real Plan Real Plan Real

…
121 Plan de Pruebas 02/01 02/01 07/02 07/02 14/02 21/02 21/02 28/02 N/C N/C

124 Bomba de Agua 02/01 02/01 13/03 13/03 14/06 30/06 14/07
…
288 | Apéndice A: Contenido básico de las Descripciones de Productos
A.23 Plan de Revisión de Beneficios
A.23.1 Propósito
Un Plan de Revisión de Beneficios tiene la función
de definir cómo y cuándo se puede calcular el
nivel de obtención de los beneficios del proyecto
que espera obtener el Usuario Principal. El plan
se presenta al Ejecutivo durante el proceso del
Inicio de un Proyecto, se actualiza en cada límite
de fase y se utiliza durante el proceso del Cierre
de un Proyecto para definir cualquier revisión de
beneficios post-proyecto que sea necesaria.
El plan tiene que cubrir las actividades para
averiguar si se han logrado los beneficios esperados
de los productos y cuál ha sido el rendimiento de
los productos durante su vida útil. Debe evaluarse
el nivel de obtención de cada beneficio esperado
y si se necesita más tiempo para evaluar los
beneficios residuales. El uso de los productos del
proyecto puede haber causado efectos secundarios,
tanto beneficiosos como adversos. Se tiene que dar
un margen de tiempo y esfuerzo para identificar y
analizar por qué no se habían previsto estos efectos
secundarios.
Si el proyecto forma parte de un programa, el Plan
de Revisión de Beneficios puede estar incluido en
el plan de obtención de beneficios del programa
y ser ejecutado a nivel de programa. Tras el
cierre del proyecto, la gerencia corporativa o del
programa mantiene y ejecuta el Plan de Revisión
de Beneficios.
A.23.2 Composición
■■ El alcance del Plan de Revisión de Beneficios,
indicando qué beneficios deben medirse
■■ Quién es responsable de los beneficios
esperados
■■ Cómo medir la obtención de los beneficios
esperados y cuándo se pueden medir
■■ Qué recursos se necesitan para realizar el
trabajo de revisión
■■ Medidas baseline en base a las que se
calcularán las mejoras
■■ Cómo se revisará el rendimiento del producto
del proyecto.
A.23.3 Derivación
■■ Business Case
■■ Descripción del Producto del Proyecto (y en
particular los criterios de aceptación)
■■ El plan de obtención de beneficios del
programa (si el proyecto forma parte de un
programa)
■■ Función de seguimiento del rendimiento
corporativo (como un centro de excelencia), si
existe alguna.
A.23.4 Formato y presentación
Un Plan de Revisión de Beneficios puede tener
varios formatos, incluyendo:
■■ Documento, hoja de cálculo o presentación de
diapositivas
■■ Datos introducidos en una herramienta de
gestión de proyectos.
A.23.5 Criterios de calidad
■■ Abarca todos los beneficios mencionados en el
Business Case
■■ Los beneficios se pueden medir y se ha dejado
constancia de las medidas baseline
■■ Describe el momento adecuado para la
medición de los beneficios y los motivos que
justifican la elección de ese momento
■■ Especifica las competencias o personas que
serán necesarias para realizar las mediciones
■■ El trabajo y el gasto necesarios para llevar a
cabo las revisiones de beneficios son realistas
en comparación con el valor de los beneficios
esperados
■■ Se plantea si se deberían medir y revisar los
contrabeneficios.
A.24 Registro de Calidad
A.24.1 Propósito
Un Registro de Calidad se utiliza para resumir
todas las actividades de gestión de calidad que se
han planificado o han tenido lugar y proporciona
información para los Informes al Final de Fase y el
Informe al Final de Proyecto. Su propósito es:
■■ Asignar una referencia única a cada actividad de
calidad
■■ Servir para identificar las fichas de calidad de un
producto
■■ Servir de resumen del número y tipo de
actividades de calidad realizadas.
 Apéndice A: Contenido básico de las Descripciones de Productos | 289
A.24.2 Composición
Para cada anotación que se haga en el Registro de
Calidad, se deberá indicar lo siguiente:
■■ Identificador de calidad: proporciona una
referencia única para cada actividad de
calidad incluida en el Registro de Calidad.
Consistirá normalmente en un valor numérico o
alfanumérico
■■ Identificador(es) del producto: identificadores
únicos para el producto o productos a los que
afecta la actividad de calidad
■■ Título(s) del producto: los nombres con los que
se conoce el producto o productos
■■ Método: el método empleado para la actividad
de calidad (por ejemplo, producto piloto,
revisión de calidad, auditoría, etc.)
■■ Roles y responsabilidades: la persona o equipo
responsable de las actividades de gestión de
calidad (por ejemplo, el auditor o, en el caso de
revisiones de calidad, el presentador, el revisor
o revisores, el presidente y el administrador)
■■ Fechas: fechas planificadas, pronosticadas y
reales para:
●● la actividad de calidad
●● la autorización que declara que la actividad
de calidad se ha completado
■■ Resultado: el resultado de la actividad de
calidad. Si un producto no se aprueba en una
revisión de calidad, cualquier revaluación que
se haga debe ser anotada por separado en el
registro cuando se haya completado la actividad
de calidad original (que queda completada al
decidirse que el resultado es que el producto no
ha sido aprobado en la revisión)
■■ Fichas de calidad: referencias a la
documentación de inspección de calidad, como
por ejemplo, un plan de prueba o información
sobre cualquier acción necesaria para
corregir errores y omisiones de los productos
inspeccionados.
A.24.3 Derivación
■■ El formato y composición del Registro de
Calidad se definirá en la Estrategia de Gestión
de la Calidad
■■ Se realizan anotaciones cuando se incluye una
actividad de calidad en el Plan de la Fase de
gestión actual. Puede actualizarse cuando se
crea un Plan del Equipo
■■ La información restante se obtiene del propio
desarrollo de la actividad de calidad
■■ La fecha de autorización es aquella en la que
todas las rectificaciones han sido autorizadas.
A.24.4 Formato y presentación
Un Registro de Calidad puede tener varios
formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Registro independiente o en forma de
actualizaciones en las actas de revisión del
progreso
■■ Datos introducidos en una herramienta de
gestión de proyectos
■■ Parte de un registro de proyecto integrado
para todos los riesgos, acciones, decisiones,
suposiciones, cuestiones, lecciones, etc.
A.24.5 Criterios de calidad
■■ Existe un procedimiento que garantizará que se
documenten en el Registro de Calidad todas las
actividades de calidad
■■ Se ha determinado quién tiene la
responsabilidad sobre el Registro de Calidad
■■ Las acciones se han descrito y asignado con
claridad
■■ Las anotaciones se han identificado de forma
única, incluyendo el producto al que se refieren
■■ El acceso al Registro de Calidad está controlado
■■ El Registro de Calidad se conserva en un lugar
seguro
■■ Todas las actividades de calidad se sitúan en el
nivel de control adecuado.
A.25 Registro de Cuestiones
A.25.1 Propósito
El propósito de un Registro de Cuestiones es
registrar y guardar información sobre todas las
cuestiones que se están gestionando formalmente.
El Project Manager deberá hacer un seguimiento
del Registro de Cuestiones con regularidad.
A.25.2 Composición
Para cada anotación que se haga en el Registro de
Cuestiones, se deberá indicar lo siguiente:
290 | Apéndice A: Contenido básico de las Descripciones de Productos
■■ Identificador de la cuestión: proporciona una
referencia única para cada cuestión incluida
en el Registro de Cuestiones. Consistirá
normalmente en un valor numérico o
alfanumérico
■■ Tipo de cuestión: define el tipo de cuestión que
se anota concretamente:
●● Solicitud de cambio
●● Fuera de especificación
●● Problema/asunto
■■ Fecha de comunicación: la fecha en la que se
planteó inicialmente la cuestión
■■ Presentada por: el nombre de la persona o
equipo que planteó la cuestión
■■ Autor del Informe de Cuestiones: el nombre de
la persona o equipo que elaboró el Informe de
Cuestiones
■■ Descripción de la cuestión: explicación en la que
se describe la cuestión, su causa y su impacto
■■ Prioridad: se debe especificar remitiéndose a
las categorías escogidas para el proyecto. La
prioridad se debe revaluar tras el análisis del
impacto
■■ Severidad: se debe especificar remitiéndose a la
escala escogida para el proyecto. La severidad
indicará qué nivel de gestión debe tomar una
decisión sobre la cuestión
■■ Estado: el estado actual de la cuestión y la
fecha de la última actualización
■■ Fecha de cierre: la fecha en que se cerró la
cuestión.
A.25.3 Derivación
■■ El formato y la composición del Registro de
Cuestiones se definirán en la Estrategia de
Gestión de la Configuración
■■ Se hacen inicialmente anotaciones en el
Registro de Cuestiones cuando se ha presentado
una nueva cuestión
■■ El Registro de Cuestiones se actualiza a medida
que progresa la cuestión. Cuando se ha resuelto
la cuestión, se cierra la anotación en el Registro
de Cuestiones.
A.25.4 Formato y presentación
Un Registro de Cuestiones puede tener varios
formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Registro independiente o en forma de
actualizaciones en las actas de revisión del
progreso
■■ Datos introducidos en una herramienta de
gestión de proyectos
■■ Parte de un registro de proyecto integrado
para todos los riesgos, acciones, decisiones,
suposiciones, cuestiones, lecciones, etc.
A.25.5 Criterios de calidad
■■ El estado indica si se han realizado acciones
■■ Las cuestiones están identificadas de forma
única, incluyendo información sobre el
producto al que se refieren
■■ Se define un proceso por el que se debe
actualizar el Registro de Cuestiones
■■ Las anotaciones del Registro de Cuestiones
que, tras ser examinadas, resulten ser riesgos,
se transfieren al Registro de Riesgos y esto se
refleja en las anotaciones correspondientes
■■ Se controla el acceso al Registro de Cuestiones y
el registro se guarda un lugar seguro.
A.26 Registro de riesgos
A.26.1 Propósito
El Registro de Riesgos proporciona un documento
para anotar los riesgos identificados en relación
al proyecto, incluyendo su estado y su historial. Se
utiliza para registrar y guardar información sobre
todas las amenazas y oportunidades identificadas
en relación al proyecto.
A.26.2 Composición
Para cada anotación que se haga en el Registro de
Riesgos, se deberá indicar lo siguiente:
■■ Identificador del riesgo: proporciona una
referencia única para cada riesgo introducido
en el Registro de Riesgos. Consistirá
normalmente en un valor numérico o
alfanumérico
■■ Autor del riesgo: la persona que planteó el
riesgo
■■ Fecha de registro: la fecha de identificación del
riesgo
■■ Categoría del riesgo: el tipo de riesgo,
remitiéndose a las categorías escogidas para el
proyecto (por ejemplo, si se refiere a cuestiones
del cronograma, calidad, legales, etc.)
 Apéndice A: Contenido básico de las Descripciones de Productos | 291

■■ Descripción del riesgo: remitiéndose a la causa,
el evento (amenaza u oportunidad) y los efectos
(descripción verbal del impacto)
■■ Probabilidad, impacto y valor esperado: resulta
útil estimar los valores inherentes (acciones
previas a la respuesta) y los valores residuales
(acciones posteriores a la respuesta). Para incluir
esta información, habría que remitirse a las
escalas escogidas para el proyecto
■■ Proximidad: esta indicará normalmente
cuánto tiempo queda para que se concrete
el acontecimiento de riesgo (por ejemplo,
inminente, durante la fase, durante el
proyecto, después del proyecto). Para indicar
la proximidad habría que remitirse a las escalas
escogidas para el proyecto
■■ Categorías de respuesta al riesgo: de qué
manera será tratado el riesgo por parte
del proyecto, remitiéndose a las categorías
escogidas para el proyecto. Por ejemplo:
●● Para amenazas: evitar, reducir, estrategia
alternativa, transferir, aceptar, compartir
●● Para oportunidades: incrementar,
aprovechar, rechazar, compartir
■■ Respuesta al riesgo: medidas para resolver
el riesgo, y estas medidas deben ajustarse a
las categorías de respuesta elegidas. Téngase
en cuenta que puede aplicarse más de una
respuesta a un riesgo en concreto
■■ Estado del riesgo: normalmente se define en
relación a si un riesgo está activo o cerrado
■■ Propietario del riesgo: la persona responsable
de gestionar el riesgo (solamente puede haber
un propietario por cada riesgo)
■■ Ejecutor de riesgo: la(s) persona(s) que
llevará(n) a cabo la(s) acción(es) descrita(s) en
la respuesta al riesgo. No tiene por qué tratarse
de la misma persona que el propietario del
riesgo.
del proyecto, se establezcan los controles del
proyecto y se desarrollen sus planes, se emitan
los Paquetes de Trabajo, se revise el estado del
Paquete de Trabajo o se revise el estado de fase
■■ Archivo Diario/Registro de Cuestiones: las
cuestiones frecuentes planteadas al Project
Manager y registradas en el Archivo Diario o
en el Registro de Cuestiones son realmente
riesgos, que sólo se identifican como tales tras
estudiarse más a fondo.
A.26.4 Formato y presentación
Un Registro de Riesgos puede tener varios
formatos, incluyendo:
■■ Documento, hoja de cálculo o base de datos
■■ Registro independiente o en forma de
actualizaciones en las actas de revisión del
progreso
■■ Datos introducidos en una herramienta de
gestión de proyectos
■■ El Registro de Riesgos puede formar parte de
un registro de proyecto integrado para todos
los riesgos, acciones, decisiones, suposiciones,
cuestiones, lecciones, etc.
A.26.5 Criterios de calidad
■■ El estado indica si se han realizado acciones
■■ Los riesgos se han identificado de forma única,
incluyendo la información relativa al producto
al que se refieren
■■ Se controla el acceso al Registro de Riesgos, que
se conserva en un lugar seguro.

A.26.3 Derivación
■■ La composición, formato y presentación del
Registro de Riesgos se derivarán de la Estrategia
de Gestión del Riesgo
■■ Las anotaciones se introducen en el Registro de
Riesgos cuando se identifica un nuevo riesgo
■■ Es posible que exista uno o más riesgos
inherentes en el mandato de proyecto
■■ Es posible que se descubran nuevos riesgos
cuando se cree el Expediente del Proyecto,
se diseñe y se nombre al equipo de gestión
 B
Apéndice B:
Gobierno
Apéndice B: Gobierno

El gobierno de la gestión del proyecto cubre
aquellas áreas de gobierno corporativo que se
relacionan específicamente con las actividades de
un proyecto. El gobierno efectivo de la gestión del
proyecto asegura que la cartera de proyectos de una
organización esté alineada con los objetivos de la
organización, que se entregue con eficiencia y que
sea sostenible. El gobierno de la gestión del proyecto
también apoya los medios mediante los cuales se
proporciona a la junta corporativa y otras principales
partes interesadas en el proyecto información
pertinente y fiable de manera oportuna.

Tabla B.1 Gobierno de los principios de gestión del proyecto de la Association for Project Management
Gobierno de los principios de gestión del proyecto
La junta tiene la responsabilidad global del gobierno de la gestión
del proyecto.
Los roles, responsabilidades y los criterios de desarrollo para el
gobierno de la gestión del proyecto están claramente definidos.
Durante todo el ciclo de vida del proyecto se aplican arreglos
disciplinados para el gobierno que están apoyados por métodos y
controles apropiados.
Se demuestra una relación coherente y de apoyo entre la estrategia Parcialmente. Cada proyecto PRINCE2 debería
comercial general y la cartera del proyecto.
Todos los proyectos cuentan con un plan aprobado que contiene
puntos de autorización al llegar a los cuales se revisa y aprueba
el Business Case. Las decisiones tomadas en los puntos de
autorización se registran y se comunican.
Los miembros de los entes de autorización delegados cuentan con
representación, competencia, autoridad y recursos suficientes para
permitirles tomar decisiones apropiadas.
El Business Case del proyecto se apoya en información pertinente y
realista que proporciona una base fiable para tomar decisiones de
autorización.
La junta o sus agentes delegados deciden cuándo se requiere
un escrutinio independiente de los proyectos y de los sistemas
de gestión de los proyectos e implementan dicho escrutinio en
conformidad.
Hay criterios claramente definidos para informar sobre el estado
del proyecto y para presentar una excepción respecto de riesgos y
cuestiones a los niveles requeridos por la organización.
¿Abordado por PRINCE2?
Este principio de gobierno se relaciona con la junta
principal de la organización corporativa y está fuera
del alcance de PRINCE2.
Parcialmente. El proyecto tiene roles,
responsabilidades y los criterios de desarrollo
claramente definidos para el gobierno, pero
PRINCE2 no se extiende a las responsabilidades de
gobierno de los roles corporativos.
Totalmente.
demostrar su alineación con la estrategia corporativa
a través de su Business Case. PRINCE2 no ofrece
pautas sobre gestión de la cartera.
Totalmente.
Parcialmente. PRINCE2 proporciona el marco
para una delegación efectiva. La competencia del
personal del proyecto está fuera del alcance de
PRINCE2.
Totalmente.
Parcialmente. PRINCE2 recomienda un escrutinio
independiente por parte de la gestión corporativa o
del programa como parte de las responsabilidades
de Garantía del Proyecto.
Totalmente.
continúa
296 | Apéndice B: Gobierno

Tabla B.1 (continuación)

Gobierno de los principios de gestión del proyecto
La organización promueve una cultura de mejora y de divulgación
interna franca de la información del proyecto.
Las partes interesadas en el proyecto participan a un nivel acorde
con su importancia para la organización y de una manera que
promueve confianza.
¿Abordado por PRINCE2?
Parcialmente. PRINCE2 alienta una estructura abierta
de presentación de informes a través de la gestión
por excepción y de las funciones de garantía.
Totalmente.

De: Directing Change: A Guide to Governance of Project Management (reimpreso con revisiones menores,
2005), APM Governance SIG. © Association for Project Management, 2004. Reproducción con permiso.

PRINCE2 proporciona (si se aplica dentro del

espíritu de sus principios) un marco para un
gobierno efectivo. La Tabla B.1 muestra la
manera en que PRINCE2 aborda los principios de
gobierno publicados por la Association for Project
Management.
 Apéndice C:

C
Roles y
responsabilidades
Apéndice C: Roles y responsabilidades
C.1 Junta de Proyecto
La Junta de Proyecto rinde cuentas ante la
gerencia corporativa o del programa por el éxito
del proyecto, y tiene la autoridad para dirigir
el proyecto dentro del marco establecido por la
gerencia corporativa o del programa, tal y como se
documenta en el mandato de proyecto.
La Junta de Proyecto también es responsable de
las comunicaciones entre el equipo de gestión del
proyecto y las partes interesadas que no formen
parte de dicho equipo (por ejemplo, la gerencia
corporativa y del programa).
Según el tamaño, complejidad, importancia y nivel
de riesgo del proyecto, los miembros de la Junta de
Proyecto pueden delegar algunas de las tareas de
Garantía del Proyecto a otras personas. La Junta de
Proyecto también puede delegar a una Autoridad
de Cambios las decisiones sobre cambios.
C.1.1 Responsabilidades generales
Durante la puesta en marcha y el inicio:
■■ Confirmar las tolerancias del proyecto con la
gerencia corporativa o del programa
■■ Aprobar el Expediente del Proyecto
■■ Aprobar el Plan de la Fase de inicio
■■ Autorizar el inicio del proyecto
■■ Decidir si se utiliza una Autoridad de Cambios
y, en ese caso, acordar el nivel de autoridad que
se debe delegar
■■ Fijar la escala de severidad para las cuestiones
■■ Fijar la escala de prioridad para las solicitudes
de cambio y fuera de especificación
■■ Aprobar el contrato del proveedor (si la relación
entre el cliente y el proveedor es de carácter
comercial)
■■ Aprobar la Documentación de Inicio del
Proyecto (y sus componentes)
■■ Autorizar el comienzo del proyecto.
Durante el proyecto:
■■ Establecer las tolerancias para cada fase y
aprobar los Planes de Fase
■■ Autorizar cada fase de gestión y aprobar las
Descripciones de Productos para cada fase
■■ Aprobar Planes de Excepción cuando se prevea
que se van a exceder las tolerancias a nivel de
fase
■■ Comunicarse con las partes interesadas del
modo definido en la Estrategia de Gestión de
la Comunicación (incluyendo el traslado de
información a la gerencia corporativa o del
programa sobre el progreso del proyecto)
■■ Proporcionar orientación y dirección generales
al proyecto, asegurándose de que siga siendo
viable y esté dentro de las restricciones
especificadas
■■ Responder a las solicitudes de asesoramiento
del Project Manager
■■ Asegurarse de que se esté llevando a cabo
un seguimiento de los riesgos y que se estén
gestionando de la forma más eficaz posible
■■ Aprobar cambios (salvo que esto se haya
delegado a una Autoridad de Cambios)
■■ Tomar decisiones sobre las excepciones
presentadas
■■ Aprobar los productos completados.
Al final del proyecto:
■■ Garantizar que se hayan entregado todos los
productos satisfactoriamente
■■ Garantizar que se hayan cumplido todos los
criterios de aceptación
■■ Confirmar la aceptación del producto del
proyecto
■■ Aprobar el Informe al Final de Proyecto y
asegurarse de que se hayan documentado y
se hayan hecho llegar a la entidad apropiada
todas las cuestiones, lecciones y riesgos
■■ Autorizar las acciones a realizar recomendadas
y los Informes sobre las Lecciones que se deban
hacer llegar a la gerencia corporativa o del
programa
■■ Pasar a la gerencia corporativa o del programa
la responsabilidad sobre el Plan de Revisión de
Beneficios actualizado
■■ Autorizar el cierre del proyecto y enviar la
notificación de cierre del proyecto a la gerencia
corporativa o del programa.
300 | Apéndice C: Roles y responsabilidades
C.1.2 Competencias
Para cumplir con su cometido, la Junta de Proyecto
debe:
■■ Tener suficiente autoridad para tomar
decisiones, aprobar planes y autorizar las
desviaciones respecto de los Planes de Fase que
puedan ser necesarias
■■ Tener suficiente autoridad para asignar recursos
al proyecto
■■ Ser capaz de representar adecuadamente
los intereses de la empresa, el usuario y el
proveedor
■■ Preferiblemente, ser capaz de permanecer en el
proyecto durante toda la vida del mismo.
Las competencias principales incluyen:
■■ Toma de decisiones
■■ Delegación
■■ Liderazgo
■■ Negociación y resolución de conflictos.
C.2 Ejecutivo
El Ejecutivo es el máximo responsable del proyecto,
con el apoyo del Usuario Principal y el Proveedor
Principal. El rol del Ejecutivo es asegurarse de que
el proyecto se centre, durante todo el tiempo que
esté en marcha, en cumplir sus objetivos y en hacer
entrega de un producto que alcance los beneficios
previstos. El Ejecutivo debe garantizar la buena
relación calidad-precio del proyecto, asegurándose
de que se desarrolle el proyecto teniendo en cuenta
los costes, así como las exigencias comerciales, del
usuario y del proveedor.
Durante todo el proyecto, el Ejecutivo es
responsable del Business Case.
La Junta de Proyecto no consiste en una
democracia controlada por votos. El Ejecutivo es
el máximo responsable en la toma de decisiones,
con el apoyo del Usuario Principal y el Proveedor
Principal.
C.2.1 Responsabilidades
Además de las responsabilidades colectivas de la
Junta de Proyecto, el Ejecutivo hará lo siguiente:
■■ Diseñar y nombrar al equipo de gestión del
proyecto (en particular, al Project Manager)
■■ Supervisar el desarrollo del Expediente del
Proyecto y del Business Case preliminar,
garantizando que el proyecto esté en
consonancia con las estrategias corporativas (y
presentando el Business Case preliminar a la
gerencia corporativa o del programa para su
aprobación, cuando sea necesario)
■■ Supervisar el desarrollo del Business Case
detallado
■■ Obtener la financiación necesaria para el
proyecto
■■ Aprobar los contratos de cualquier proveedor
adicional (si la relación entre el usuario y el
proveedor es de carácter comercial)
■■ Ser el encargado de pedir cuentas al Proveedor
Principal por la calidad e integridad del
enfoque especializado y los productos
especializados creados para el proyecto
■■ Ser el encargado de pedir cuentas al Usuario
Principal por la materialización de los beneficios
definidos en el Business Case, asegurándose de
que se realicen revisiones de beneficios para
hacer un seguimiento de la medida en que se
obtienen los beneficios del Business Case
■■ Transferir a la gerencia corporativa o del
programa la responsabilidad sobre las revisiones
de beneficios post-proyecto
■■ Realizar un seguimiento y control del progreso
del proyecto a nivel estratégico, en particular
revisando el Business Case con frecuencia
■■ Presentar excepciones a la gerencia corporativa
o del programa si se prevé que se van a superar
las tolerancias del proyecto
■■ Asegurarse de que se identifiquen, evalúen y
controlen los riesgos asociados al Business Case
■■ Tomar decisiones sobre las excepciones
presentadas teniendo especialmente en cuenta
la justificación comercial continua
■■ Organizar y presidir las revisiones de la Junta de
Proyecto
■■ Asegurar a nivel general la garantía comercial
del proyecto, con el objetivo de que el proyecto
siga su curso para hacer entrega de los
productos que permitan obtener los beneficios
comerciales esperados y que el proyecto se
complete dentro de las tolerancias acordadas.
Cuando proceda, delegar algunas de las
actividades comerciales en materia de Garantía
del Proyecto (véase la sección C.7).

C.3 Usuario Principal
El Usuario Principal (o Usuarios Principales) es
responsable de especificar las necesidades de
quienes utilizarán los productos del proyecto, así
como de servir de enlace entre los usuarios y el
equipo de gestión del proyecto y controlar que
la solución ofrecida por el proyecto cubrirá esas
necesidades dentro de los límites impuestos por el
Business Case en lo relativo a calidad, funcionalidad
y facilidad de uso.
El rol representa los intereses de aquellos que
utilizarán los productos del proyecto (incluyendo
uso y mantenimiento), de aquellos para quienes el
proyecto cumplirá un objetivo o de aquellos que
utilizarán los productos para aportar beneficios
comerciales. El rol del Usuario Principal asigna
los recursos del usuario y hace el seguimiento de
los productos según los requisitos. Es posible que
este rol necesite más de una persona para abarcar
todos los intereses del nivel usuario. Para que sea
eficaz, el rol no deberá dividirse entre demasiadas
personas.
El Usuario Principal especifica los beneficios y rinde
cuentas mediante la demostración a la gerencia
corporativa o del programa de que efectivamente
se han materializado los beneficios previstos
que sirvieron como base para la aprobación
del proyecto. Es probable que sus funciones se
extiendan más allá del período de duración del
proyecto.
C.3.1 Responsabilidades
Además de las responsabilidades colectivas de la
Junta de Proyecto, el Usuario Principal (o Usuarios
Principales) hará lo siguiente:
■■ Proporcionar las expectativas de calidad del
cliente y definir los criterios de aceptación para
el proyecto
■■ Asegurarse de que se haya especificado el
resultado deseado del proyecto
■■ Asegurarse de que el proyecto cree productos
que ofrecerán los resultados deseados y
cumplirán con las exigencias del usuario
■■ Asegurarse de que se materialicen los beneficios
esperados (derivados de los resultados del
proyecto)
■■ Proporcionar en las revisiones de beneficios una
descripción de los beneficios que compare las
previsiones con los beneficios reales
Apéndice C: Roles y responsabilidades | 301
■■ Resolver los conflictos entre exigencias y
prioridades del usuario
■■ Asegurarse de que todos los recursos del
usuario necesarios para el proyecto (por
ejemplo, para llevar a cabo inspecciones de
calidad y aprobaciones de los productos por
parte del usuario) estén disponibles
■■ Tomar decisiones sobre las excepciones
presentadas teniendo especialmente en cuenta
la preservación de los beneficios esperados
■■ Informar y asesorar a la gerencia del usuario
sobre todos los aspectos del proyecto
■■ Mantener la estabilidad del rendimiento
comercial durante la transición del proyecto a
las actividades comerciales regulares
■■ Proporcionar la opinión del usuario sobre las
acciones a realizar recomendadas
■■ Encargarse de la Garantía del Proyecto desde la
perspectiva del usuario (garantía del usuario) y,
cuando sea necesario, delegar actividades del
usuario en materia de Garantía del Proyecto
(véase la sección C.7).
C.4 Proveedor Principal
El Proveedor Principal representa los intereses
de quienes diseñan, desarrollan, facilitan,
proporcionan e implementan los productos del
proyecto. Este rol es responsable de la calidad
de los productos entregados por el proveedor
o proveedores y de la integridad técnica del
proyecto. Si es necesario, existirá más de una
persona para representar a los proveedores.
Dependiendo de la relación específica entre cliente
y proveedor, el cliente podría también designar a
una persona o grupo independiente para llevar a
cabo las actividades de garantía de los productos
del proveedor (por ejemplo, si la relación entre el
cliente y el proveedor es de carácter comercial).
C.4.1 Responsabilidades
Además de las responsabilidades colectivas de la
Junta de Proyecto, el Proveedor Principal hará lo
siguiente:
■■ Evaluar y confirmar la viabilidad del enfoque
del proyecto
■■ Asegurarse de que las propuestas para el diseño
y desarrollo de los productos sean realistas
■■ Asesorar sobre la elección de los métodos de
diseño, desarrollo y aceptación
302 | Apéndice C: Roles y responsabilidades
■■ Asegurarse de que todos los recursos del
proveedor necesarios para el proyecto estén
disponibles
■■ Tomar decisiones sobre las excepciones
presentadas teniendo especialmente en cuenta
la protección de la integridad de toda la
solución
■■ Resolver los conflictos entre los requisitos y las
prioridades de los proveedores
■■ Informar a la gerencia no técnica sobre los
aspectos del proyecto relacionados con los
proveedores
■■ Asegurarse de que se estén utilizando
correctamente los procedimientos de calidad,
de modo que los productos cumplan con los
requisitos
■■ Encargarse de la Garantía del Proyecto desde
la perspectiva del proveedor (garantía del
proveedor) y, cuando sea necesario, delegar
actividades del proveedor en materia de
Garantía del Proyecto (véase la sección C.7).
C.5 Project Manager
El Project Manager cuenta con la autoridad para la
gestión diaria del proyecto, en nombre de la Junta
de Proyecto y dentro de los límites establecidos por
la misma.
La responsabilidad principal del Project Manager
es asegurarse de que el proyecto cree los productos
exigidos, dentro de las tolerancias de tiempo, coste,
calidad, alcance, riesgo y beneficios especificadas.
El Project Manager también es responsable de
que el proyecto produzca un resultado capaz de
obtener los beneficios definidos en el Business
Case.
C.5.1 Responsabilidades
Las responsabilidades del Project Manager incluyen
las siguientes:
■■ Preparar las versiones baseline de los siguientes
productos de gestión, junto con cualquier rol de
Garantía del Proyecto, y acordarlas con la Junta
de Proyecto:
●● Expediente del Proyecto, incluyendo la
Descripción del Producto del Proyecto
●● Plan de Revisión de Beneficios
●● Documentación de Inicio del Proyecto (y sus
componentes)
●● Planes de Fase y de Excepción y sus
Descripciones de Productos
●● Paquetes de Trabajo
■■ Preparar los siguientes informes:
●● Informes de Desarrollo
●● Informes de Cuestiones
●● Informes al Final de Fase
●● Informes sobre las Lecciones
●● Informes de Excepción
●● Informe al Final de Proyecto
■■ Mantener las siguientes fichas:
●● Registro de Cuestiones
●● Registro de Riesgos
●● Archivo Diario
●● Archivo sobre las Lecciones
■■ Coordinarse con la gerencia corporativa o del
programa para garantizar que otros proyectos
relacionados no pasen por alto ni dupliquen
ninguna tarea
■■ Coordinarse con los proveedores o gestores de
cuentas externos que pudieran existir
■■ Dirigir y motivar al equipo de gestión del
proyecto
■■ Asegurarse de que se determine el
comportamiento esperado de los miembros del
equipo
■■ Gestionar los flujos de información entre los
niveles de dirección y de entrega del proyecto
■■ Gestionar la creación de los productos exigidos,
asumiendo la responsabilidad del progreso
general y del uso de los recursos, y poner en
marcha rectificaciones cuando sea necesario
■■ Establecer y gestionar los procedimientos
del proyecto – gestión del riesgo, control
de cambios y cuestiones, gestión de la
configuración y comunicación
■■ Establecer y gestionar los controles del proyecto
– seguimiento e información
■■ Autorizar Paquetes de Trabajo
■■ Informar a la Junta de Proyecto de cualquier
desviación respecto del plan
■■ Desempeñar el rol de Team Manager, salvo que
se haya asignado a otra persona o personas
(véase la sección C.6)
■■ Desempeñar el rol de Apoyo al Proyecto, salvo
que se haya asignado a otra persona (o a otra
función corporativa o del programa) (véase la
sección C.9)
 Apéndice C: Roles y responsabilidades | 303

■■ Aplicar la Estrategia de Gestión de la ■■ Identificar e informar al Project Manager sobre

Configuración cualquier cuestión o riesgo asociado a un
■■ Asegurarse de que el personal del proyecto Paquete de Trabajo
cumpla con la Estrategia de Gestión de la ■■ Informar al Project Manager sobre cualquier
Configuración desviación respecto al plan, recomendar
■■ Programar auditorías de la configuración para rectificaciones y ayudar a elaborar los Planes de
comprobar que los productos físicos coinciden Excepción necesarios
con las Fichas de Elementos de Configuración y ■■ Entregar al Project Manager los productos que
poner en marcha cualquier rectificación que sea se hayan completado y aprobado, de acuerdo
necesaria. con los requisitos acordados en el Paquete de
Trabajo
C.5.2 Competencias ■■ Coordinarse con los roles de Garantía del
Diferentes tipos de proyecto requerirán diferentes Proyecto y Apoyo al Proyecto
tipos de competencias de gestión de proyectos. ■■ Asegurarse de que se hayan planificado y
Para ser eficiente, el Project Manager debe ser realizado correctamente las actividades de
capaz de adaptar los diferentes aspectos del rol calidad respecto del trabajo del equipo y que
de Project Manager a las necesidades de cada estén dentro de las tolerancias
proyecto concreto. ■■ Asegurarse de que se hayan realizado las
Las competencias principales incluyen: anotaciones pertinentes en el Registro de
Calidad
■■ Planificación ■■ Gestionar cuestiones y riesgos específicos,
■■ Gestión del tiempo siguiendo las instrucciones del Project Manager
■■ Gestión de personas ■■ Ayudar al Project Manager en el examen de
■■ Solución de problemas cuestiones y riesgos
■■ Atención al detalle ■■ Asegurarse de que se haya informado
■■ Comunicación correctamente a la persona encargada de
■■ Negociación mantener el Registro de Cuestiones sobre todas
■■ Gestión de conflictos. las cuestiones asignadas.

C.6.2 Competencias
C.6 Team Manager
Diferentes tipos de proyecto requerirán diferentes
La principal responsabilidad del Team Manager es tipos de competencias por parte del Team
garantizar la creación de los productos definidos Manager.
por el Project Manager con la calidad apropiada,
Las competencias principales son similares a las de
dentro de los plazos determinados y con un coste
un Project Manager.
aceptable para la Junta de Proyecto. Los Team
Managers dependen del Project Manager, de quien
reciben las instrucciones. C.7 Garantía del Proyecto
La Garantía del Proyecto cubre los intereses de las
C.6.1 Responsabilidades principales partes interesadas (comercial, usuario y
■■ Preparar el Plan de Equipo y acordarlo con el proveedor).
Project Manager
La Garantía del Proyecto debe ser independiente
■■ Elaborar los Informes del Punto de Control
del Project Manager y, por lo tanto, la Junta
según lo acordado con el Project Manager
de Proyecto no puede delegar ninguna de sus
■■ Planificar, supervisar y gestionar el trabajo del
actividades de garantía en el Project Manager.
equipo
■■ Ser responsable del progreso del trabajo del
equipo y del uso de sus recursos, así como de
poner en marcha las rectificaciones necesarias,
dentro de los límites establecidos por el Project
Manager
304 | Apéndice C: Roles y responsabilidades
C.7.1 Responsabilidades
Para la implementación de las responsabilidades
de garantía se necesita responder a la siguiente
pregunta: ¿Qué se tiene que garantizar? Un listado
inicial de los intereses a garantizar por las partes
interesadas (comercial, usuario y proveedor) podría
incluir que:
■■ Se mantenga una estrecha relación entre la
empresa, el usuario y el proveedor durante
todo el proyecto
■■ Se controlen los riesgos
■■ Las personas que trabajan en la tarea de
preparar las Descripciones de Productos sean las
adecuadas
■■ Está previsto que las personas adecuadas
lleven a cabo la inspección de calidad en los
momentos apropiados del desarrollo de los
productos
■■ Se haya dado la formación adecuada al
personal sobre los métodos de calidad
■■ Los métodos de calidad se estén siguiendo
correctamente
■■ Se estén gestionando correctamente las
acciones a realizar con respecto al control de
calidad
■■ Se esté desarrollando una solución aceptable
■■ El alcance del proyecto no esté variando sin
autorización
■■ La comunicación tanto internas como externa
esté funcionando correctamente
■■ Se estén siguiendo las normas aplicables
■■ Se estén teniendo en cuenta las necesidades
de intereses especializados (por ejemplo,
seguridad).
Responsabilidades de la garantía comercial
■■ Ayudar al Project Manager a elaborar el
Business Case y el Plan de Revisión de Beneficios
(si corresponde al Project Manager prepararlo)
■■ Asesorar sobre la selección de miembros del
equipo de gestión del proyecto
■■ Asesorar sobre la Estrategia de Gestión del
Riesgo
■■ Revisar el Business Case para asegurarse de
que cumple con las normas de la empresa y del
programa que sean aplicables
■■ Verificar el Business Case, comparándolo con
acontecimientos externos y con el progreso del
proyecto
■■ Comprobar que se observa el Business Case
durante todo el proyecto
■■ Comprobar que el proyecto no se aparta en
ningún momento de la estrategia corporativa o
del programa
■■ Revisar las finanzas del proyecto en nombre del
cliente
■■ Verificar que la solución continúa teniendo una
buena relación calidad-precio
■■ Comprobar periódicamente que el proyecto
sigue siendo viable
■■ Verificar que la exposición al riesgo agregada se
mantiene dentro de la tolerancia del proyecto
■■ Comprobar que se autorizan todos los pagos a
proveedores y contratistas
■■ Revisar cuestiones y riesgos mediante la
evaluación de su impacto en el Business Case
■■ Restringir los excesos del usuario y del
proveedor
■■ Informar al equipo de gestión del proyecto
sobre cualquier cambio causado por un
programa del que el proyecto forme parte
(esta responsabilidad se puede transferir si el
programa está representado de otro modo en
el equipo de gestión del proyecto)
■■ Controlar el progreso de la fase y del proyecto,
comparándolo con las tolerancias acordadas.
Responsabilidades de la garantía del usuario
■■ Informar sobre el nivel de participación de las
partes interesadas
■■ Asesorar sobre la Estrategia de Gestión de la
Comunicación
■■ Asegurarse de que la especificación de las
necesidades del usuario sea correcta, completa
e inequívoca
■■ Evaluar si la solución cubrirá las necesidades
del usuario y si se está progresando hacia ese
objetivo
■■ Asesorar sobre el impacto de posibles cambios
desde el punto del vista del usuario
■■ Hacer un seguimiento de los riesgos para el
usuario
■■ Asegurarse de que las actividades de calidad
relativas a los productos en todas las fases
cuenten con la apropiada representación del
usuario
 Apéndice C: Roles y responsabilidades | 305

■■ Asegurarse de que se hayan utilizado C.8 Autoridad de Cambios

correctamente los procedimientos de control
La Junta de Proyecto puede delegar la autoridad
de calidad para garantizar que los productos
de aprobar respuestas a solicitudes de cambio o
cumplan con las exigencias del usuario
fuera de especificación a una persona o grupo
■■ Asegurarse de que la coordinación con el
fuera de la Junta, que se conoce como Autoridad
usuario esté funcionando de modo eficaz.
de Cambios. El Project Manager podría ser
Responsabilidades de la garantía del proveedor designado como Autoridad de Cambios para
algunos aspectos del proyecto (por ejemplo, para
■■ Revisar las Descripciones de Productos
cambiar las versiones baseline de los Paquetes de
■■ Asesorar sobre la Estrategia de Gestión de
Trabajo si ello no afecta a las tolerancias de la fase).
la Calidad y la Estrategia de Gestión de la
Configuración
C.8.1 Responsabilidades
■■ Asesorar sobre la selección de la estrategia, el
■■ Revisar y aprobar o rechazar todas las
diseño y los métodos de desarrollo
solicitudes de cambio y fuera de especificación
■■ Asegurarse de que se estén cumpliendo y
dentro de los límites de la autoridad delegada y
utilizando de forma eficaz todas las normas
del presupuesto de cambios establecidos por la
operativas y del proveedor establecidas para el
Junta de Proyecto
proyecto
■■ Informar a la Junta de Proyecto en el caso de
■■ Asesorar sobre posibles cambios y su impacto
que se prevea que se van a exceder los límites
en la precisión, integridad y nivel de desarrollo
de autoridad delegada o el presupuesto de
de los productos en comparación con sus
cambios asignado.
Descripciones de Productos, desde la perspectiva
del proveedor
C.8.2 Competencias
■■ Hacer el seguimiento de cualquier riesgo en los
aspectos de producción del proyecto La Autoridad de Cambios debe:
■■ Evaluar si se están utilizando correctamente los ■■ Ser capaz de representar adecuadamente los
procedimientos de control de calidad, para que intereses de las partes interesadas (comercial,
los productos cumplan las exigencias. usuario y proveedor)
■■ Tener suficiente credibilidad para asegurarse de
C.7.2 Competencias que se sigan sus consejos y orientación
Para cumplir con su cometido, la Garantía del ■■ Tener conocimientos especializados suficientes
Proyecto debe: de los ámbitos de actividad de las partes
interesadas (comercial, usuario o proveedor).
■■ Ser capaz de representar adecuadamente los
intereses de la parte interesada (comercial, Las competencias principales incluyen:
usuario o proveedor) ■■ Toma de decisiones
■■ Tener suficiente credibilidad para garantizar
■■ Planificación
que se sigan sus consejos y orientación
■■ Atención al detalle
■■ Tener suficientes conocimientos especializados
■■ Solución de problemas.
de los ámbitos de actividad de la parte
interesada (comercial, usuario o proveedor)
■■ Preferiblemente, ser capaz de permanecer en el
proyecto durante todo su ciclo de vida.
Las competencias principales incluyen:
■■ Diplomacia
■■ Rigurosidad
■■ Atención al detalle
■■ Comunicación.
306 | Apéndice C: Roles y responsabilidades

C.9 Apoyo al Proyecto ●● Proporcionar información sobre el estado

de todos los productos (mediante la
La existencia de un Apoyo al Proyecto formal es
preparación y distribución de informes sobre
opcional. Si no se delega a otra persona o función,
el estado de los productos)
tendrá que ser asumido por el Project Manager.
●● Archivar copias obsoletas de los productos
Una de las funciones de apoyo que se debe ●● Garantizar la seguridad y conservación de las
considerar es la de gestión de la configuración. copias originales de todos los productos del
Dependiendo del tamaño y entorno del proyecto, proyecto
es posible formalizar esta función y que Project ●● Mantener un registro de todas las copias
Manager no pueda desempeñar esta tarea sin emitidas
apoyo.
●● Informar a los poseedores de copias sobre
Las funciones de Apoyo al Proyecto pueden ser cualquier cambio en las mismas
desarrolladas por una Oficina de Proyecto o ●● Numerar, registrar, almacenar y distribuir
por recursos específicos asignados al proyecto. Informes de Cuestiones.
Véase la guía de OGC Portfolio, Programme ●● Llevar a cabo auditorías de la configuración.
and Project Support Office (2008) para obtener
más información sobre el uso de una Oficina de C.9.2 Competencias
Proyecto.
Las competencias típicas de los roles de Apoyo
al Proyecto dependerán del tipo de proyecto y
C.9.1 Responsabilidades organización.
A continuación se sugiere una lista de tareas:
Las competencias principales incluyen:
■■ Establecer y mantener los archivos del proyecto
■■ Administración y organización
■■ Establecer los procedimientos de control de los
■■ Conocimiento de herramientas y técnicas
documentos
especializadas
■■ Reunir información real y pronósticos
■■ Conocimiento de las normas de la gerencia
■■ Actualizar planes
corporativa o del programa, aplicables al
■■ Administrar o ayudar con el proceso de la
proyecto.
revisión de calidad
■■ Administrar o ayudar con las reuniones de la
Junta de Proyecto
■■ Ayudar con la elaboración de informes
■■ Contribuir con conocimientos sobre el uso
de herramientas o técnicas especializadas
(por ejemplo, herramientas de planificación y
control, análisis de riesgo)
■■ Mantener las siguientes fichas:
●● Registro de Calidad
●● Fichas de Elementos de Configuración
●● Cualquier otro registro/archivo delegado por
el Project Manager
■■ Administrar el procedimiento de gestión de
la configuración (estas funciones pueden
ser desempeñadas por un bibliotecario de la
configuración que forme parte de la gerencia
corporativa o del programa):
●● Administrar la recepción, identificación,
control de versiones, almacenamiento y
emisión de todos los productos del proyecto
 D
Apéndice D:
Ejemplo de
planificación basada
en el producto
Apéndice D: Ejemplo de planificación
basada en el producto

D.1 Escenario direcciones que se puede utilizar para el mailing.

Cuando se reserve el lugar de celebración, el equipo
Se necesita un proyecto para organizar y llevar a
de proyecto tendrá que preparar y publicar una
cabo una conferencia para un grupo de entre 80
nota de prensa basada en el programa. El proyecto
y 100 asistentes. Se han decidido la fecha elegida
también requiere la producción de cien copias
y el tema de la conferencia. El objetivo principal
de la carpeta de información para los asistentes,
es informar a los miembros de una determinada
cuya portada deberá reflejar el tema escogido. Las
profesión acerca de las últimas novedades
carpetas deberán contener el horario del programa
sobre los desarrollos más recientes y sobre las
acordado, copias de las diapositivas y de los apuntes
actualizaciones de las normas. El equipo de proyecto
que los ponentes utilizarán y un formulario para
tendrá que primero identificar un lugar donde se
que los asistentes expresen su opinión sobre la
pueda celebrar la conferencia, luego comprobar
conferencia. Detalles sobre cómo realizar las
si está disponible, qué servicios ofrece y cuánto
reservas para participar en la conferencia se deberán
cuesta y finalmente hacer la reserva. Se tienen
incluir en el mailing. El equipo de proyecto deberá
que identificar los ponentes apropiados, con los
actualizar frecuentemente la lista de asistentes
que habrá que ponerse en contacto y acordar
con las respuestas recibidas y, basándose en la lista
su participación, antes de producir una agenda
actualizada, tendrán que contratar personal para el
y programa detallados. Ya existe una lista de
día de la conferencia.

Figura D.1 Estructura jerárquica

de productos en forma de
gráfico jerárquico
310 | Apéndice D: Ejemplo de planificación basada en el producto

Tabla D.1 Ejemplo de una Descripción del Producto del Proyecto para una conferencia anual

Nombre Conferencia anual

Propósito La conferencia es el evento que reúne a los miembros de la profesión cada año y ofrece a los
asistentes la oportunidad de conocer las últimas novedades sobre los desarrollos y normas que
afectan a la profesión, así como establecer contactos con otros profesionales.
Composición ■■ Lugar de celebración de la conferencia
■■ Asistentes
■■ Ponentes
■■ Publicidad
■■ Carpeta de información para los asistentes
■■ Logística de la conferencia.
Derivación ■■ Tema elegido
■■ Lista de direcciones
■■ Lecciones y materiales de conferencias anteriores
■■ Fecha acordada.
Competencias ■■ Gestión de la conferencia
necesarias para el ■■ Marketing
desarrollo ■■ Relaciones públicas.
Expectativas de calidad Prioridad 1: La conferencia debe ser:
del cliente ■■ De estilo profesional, financiada por los asistentes y debe cubrir las necesidades de
miembros con perfiles distintos (desde principiantes hasta profesionales con mucha
experiencia)
■■ El evento ofrecerá la posibilidad de establecer contactos con otros profesionales
■■ La conferencia dejará satisfechos a los asistentes, haciendo que tengan interés en participar
en futuras conferencias.
Prioridad 2:
■■ Se escogerá a los ponentes de acuerdo con sus conocimientos, su experiencia y su nivel de
especialización. Los ponentes no deben dar la impresión que están tratando de vender un
producto
■■ La conferencia tendrá un estilo interactivo
■■ La conferencia se celebrará en un lugar céntrico para evitar en la medida de lo posible los
desplazamientos.
Criterios de aceptación En orden de prioridad:
y tolerancias de calidad ■■ El coste de la conferencia debe quedar cubierto por el precio pagado por los asistentes
a nivel de proyecto ■■ El número de asistentes a la conferencia se encuentra entre un mínimo de 80 y un máximo
de 100
■■ Más del 50% de las ponencias tienen carácter interactivo (con formato de sesiones
participativas en vez de disertaciones en forma de monólogo)
■■ Los ponentes y el programa están aprobados por la junta editorial, que representa los
intereses de los miembros
■■ La encuesta sobre la satisfacción de los asistentes indica que más del 75% tienen intención
de asistir a la conferencia del año siguiente y/o recomendarla a otros colegas de su
profesión
■■ El hotel de la conferencia se encuentra a menos de cinco kilómetros de una estación de
tren importante.
Método de aceptación Como la conferencia no es algo que se pueda repetir si resulta ser inaceptable, la Junta de
Proyecto tendrá que confirmar su:
■■ Aceptación preliminar – basada en la aprobación del programa acordado por la junta
editorial y en la confirmación, por métodos que aseguren la imparcialidad, de que las
previsiones sobre el número de asistentes y los costes de la conferencia son aceptables
■■ Aceptación final – basada en que el Informe al Final de Proyecto ofrezca datos que
muestren que se han cumplido los criterios de aceptación.
Responsabilidades de ■■ El Usuario Principal y el Ejecutivo son responsables de confirmar la aceptación.
aceptación
 Apéndice D: Ejemplo de planificación basada en el producto | 311

Figura D.2 Estructura jerárquica de productos en forma de mapa conceptual

D.2 Ejemplo de una Descripción del D.3 Ejemplos de una estructura

Producto del Proyecto
La Tabla D.1 proporciona un ejemplo de
Descripción del Producto del Proyecto para una
conferencia anual
jerárquica de productos
PRINCE2 no especifica el formato que debe tener
una estructura jerárquica de productos. Se ofrecen
tres ejemplos de formato para el proyecto de la
conferencia:
■■ Gráfico jerárquico (Figura D.1)
■■ Mapa conceptual (Figura D.2)
■■ Lista con varios niveles.

Estructura jerárquica de productos en forma de lista con varios niveles

Conferencia
1 Lugar de celebración
1.1 Requisitos del lugar de celebración
1.2 Posibles lugares de celebración
1.3 Evaluaciones de los posibles
lugares de celebración
1.4 Lugar de celebración elegido y reservado
2 Asistentes
2.1 Lista de direcciones (externo)
2.2 Respuestas (externos)
2.3 Procedimiento de reserva de plazas
2.4 Lista final de asistentes
3 Ponentes
3.1 Posibles ponentes
3.2 Invitaciones para participar como ponente
3.3 Ponentes concertados
4 Publicidad
4.1 Mailing a posibles participantes
4.2 Nota de prensa
5 Carpeta de información para los asistentes
5.1 Portadas
5.2 Horario impreso
5.3 Diapositivas y apuntes
5.4 Encuesta de satisfacción
6 Logística de la conferencia
6.1 Tema elegido (externo)
6.2 Fecha acordada (externo)
6.3 Programa acordado
6.4 Personal para el día de la conferencia
7 Lecciones y materiales de conferencias
anteriores (externos).
312 | Apéndice D: Ejemplo de planificación basada en el producto

D.4 Ejemplo de una Descripción de Producto

Identificador Conferencia/4.1/versión 1.0

Título Mailing

Propósito El mailing es el medio principal para anunciar la conferencia a los posibles

asistentes. Será enviado a una lista de profesionales que trabajan en la industria.

Composición • Sobre para el mailing

• Carta con una breve explicación de la conferencia
• Folleto con una explicación detallada de la conferencia, el lugar de celebración
y la manera de hacer una reserva
• Impreso de reserva
• Sobre para respuestas

Derivación • Lista de direcciones

• Programa acordado
• Procedimiento de reserva de plazas
• Lugar de celebración elegido

Formato y La carta deberá ser tamaño A4 y en papel membretado

presentación
El folleto y el impreso de reserva deberán ser tamaño A5
El sobre para el mailing deberá ser tamaño C5

Aptitudes necesarias Se requieren aptitudes en marketing, diseño y redacción publicitaria

para el desarrollo
Se requieren conocimientos en materia de conferencias

Responsabilidades • Productor – Empresa gestora del evento

de calidad
• Revisores – como se indica en “Aptitudes de calidad requeridas”
• Aprobador – Secretario de afiliación

Criterios de calidad Tolerancia de calidad Método de calidad Aptitudes de calidad requeridas

Cumple las normas de Como se define en las Revisión de calidad de Equipo de marketing
identidad corporativa normas de identidad PRINCE2

La carta y el folleto Ninguna Inspección Project Manager a cargo

reflejan con exactitud todos de la conferencia
los detalles de la conferencia
que se han acordado

No hay errores de Ninguna Corrector ortográfico del Corrector de pruebas

ortografía ni de gramática procesador de textos
en ningún elemento
del mailing Inspección

La carta adjunta ocupa Puede ocupar el dorso Inspección Corrector de pruebas

sólo un lado de una hoja de una sola hoja A4
A4
 Apéndice D: Ejemplo de planificación basada en el producto | 313

D.5 Diagrama de flujo de los productos

6.2
Fecha
6.1
acordada
Tema
elegido
1.1 Requisitos del
lugar de celebración

3.1 Posibles
ponentes
2.3 Procedimiento
1.2 Posibles lugares de reserva de plazas
de celebración
3.2 Invitaciones
para participar
como ponente
1.3 Evaluaciones de
posibles lugares
de celebración
3.3 Ponentes
concertados 2.1 Lista
1.4 Lugar de de
celebración elegido direcciones
y reservado
6.3 Programa
acordado

5.4 4.2 Nota 4.1 Mailing

5.3 5.2
5.1 Encuesta de de prensa
Diapositivas Horario
Portadas satisfacción
y apuntes impreso

5 Carpeta de información 2.4 Lista final 2.2

para los asistentes de asistentes Respuestas

7
Lecciones y
materiales de 6.4 Personal
conferencias
anteriores para el día de
la conferencia

Conferencia

Figura D.3 Ejemplo de un diagrama de flujo de los productos para el proyecto de la conferencia
Nota: Solamente el producto del proyecto, las releases y los productos necesitan ser trasladados de la
estructura jerárquica de productos al diagrama de flujo de los productos. Por ejemplo, en este escenario el
planificador ha utilizado “4 Publicidad” en la estructura jerárquica de productos pero los únicos productos
publicitarios que se tienen que desarrollar son “4.1 Mailing” y “4.2 Nota de prensa”. “4. Publicidad” no es
un producto que implique trabajo, sino una manera fácil de referirse a los productos que dan publicidad
a la conferencia, mientras que “5 Carpeta de información para los asistentes” es un producto, que se
crea juntando “5.1 portadas”, “5.2 Horario impreso”, “5.3 Diapositivas y apuntes” y “5.4 Encuestas de
satisfacción” que son a su vez productos.
 Apéndice E:
Verificaciones E
Apéndice E: Verificaciones

Las siguientes son listas de control orientadas a
los procesos, que se pueden utilizar en diversos
puntos del proyecto para establecer que se estén
abordando debidamente los aspectos principales
de PRINCE2. Las listas de control no son exhaustivas
pero deberían proporcionar suficiente confianza
sobre si un proyecto se está gestionando de
conformidad con PRINCE2.
Es importante notar que cualquier referencia a
un producto de gestión significa ‘de conformidad
con la Descripción de Producto en el Apéndice A’
y en particular los criterios de calidad para esos
productos de gestión también se deberían revisar.

E.1 Puesta en Marcha de un Proyecto

Pregunta Sí/No
1 ¿Se han asignado los roles del equipo de gestión del proyecto para el:
a Ejecutivo?
b Project Manager?
c Usuario(s) Principal(es)?
d Proveedor(es) Principal(es)? – si es apropiado en este momento.
e Apoyo al Proyecto?
f Team Managers? – si es apropiado en este momento.
g Garantía del Proyecto?
h Autoridad de Cambios? – si es apropiado en este momento.
2 ¿Tienen los miembros de la Junta de Proyecto autoridad, disponibilidad y credibilidad suficientes para
dirigir el proyecto?
3 ¿Están las partes interesadas del proyecto suficientemente representadas por la Junta de Proyecto?
4 ¿Existen descripciones de roles para cada nombramiento principal?
5 El personal nombrado ¿ha confirmado su aceptación?
6 ¿Se ha establecido un Archivo Diario?
7 ¿Se ha establecido el Archivo sobre las Lecciones?
8 ¿Se han identificado y aplicado, si es apropiado, las lecciones de proyectos anteriores similares?
9 Si la organización no ha realizado un proyecto como éste anteriormente, ¿hay lecciones de proyectos
externos a la organización comparables que se pueden aprender?
10 ¿Se ha producido el Expediente del Proyecto?
11 ¿Hay un Business Case preliminar?
12 ¿Se ha producido la Descripción del Producto del Proyecto?
13 ¿Se ha decidido el enfoque del proyecto?
14 ¿Hay un Plan de la Fase de Inicio?
318 | Apéndice E: Verificaciones

E.2 Dirección de un Proyecto

E.2.1 Autorizar el inicio

Pregunta Sí/No
15 La Junta de Proyecto, ¿ha aprobado el Expediente del Proyecto? Específicamente, ¿ha:
■■ confirmado la definición y el enfoque del proyecto?
■■ revisado y aprobado la Descripción del Producto del Proyecto?
■■ formalmente confirmado los nombramientos al equipo de gestión del proyecto básico?
■■ revisado y aprobado el Business Case preliminar, en particular los beneficios esperados?
16 La Junta de Proyecto, ¿ha aprobado el Plan de la Fase de Inicio? Específicamente, ¿ha:
■■ aprobado el plan para desarrollar la Documentación de Inicio del Proyecto?
■■ obtenido o asignado los recursos que el Plan de la Fase necesita para la fase de inicio?
■■ asegurado que haya mecanismos de presentación de informes y control adecuados para la fase de
inicio?
■■ fijado tolerancias para la fase de inicio?
■■ solicitado el apoyo logístico necesario (por ejemplo, alojamiento, medios de comunicación, equipos
y cualquier Apoyo al Proyecto) de la gerencia corporativa o del programa?
■■ confirmado que han comprendido cualquier riesgo que afecta la decisión de autorizar la fase de
inicio?
■■ confirmado al Project Manager que se puede iniciar el trabajo definido en el Plan de la Fase de
Inicio?
17 La Junta de Proyecto, ¿ha informado a la gerencia corporativa o del programa (y a otras partes
interesadas) que el inicio del proyecto ha sido autorizado?

E.2.2 Autorizar el proyecto

Pregunta Sí/No
18 La Junta de Proyecto, ¿ha aprobado la Documentación de Inicio del Proyecto? Específicamente, ¿ha:
■■ confirmado que el Business Case es viable, deseable y alcanzable y que satisface las expectativas y
las normas de la gerencia corporativa o del programa y lo ha aprobado?
■■ confirmado que las lecciones de proyectos similares anteriores han sido revisadas e incorporadas?
■■ confirmado que la Estrategia de Gestión de la Calidad satisfará las expectativas de calidad y la ha
aprobado?
■■ confirmado que la Estrategia de Gestión de la Configuración satisfará el enfoque previsto y la ha
aprobado?
■■ confirmado que la Estrategia de Gestión del Riesgo protegerá el proyecto y la ha aprobado?
■■ confirmado que ha habido una evaluación de riesgo y que se han planificado acciones de respuesta
al riesgo?
■■ confirmado que el Plan de Proyecto es válido y alcanzable y lo ha aprobado?
■■ confirmado que el Plan de Revisión de Beneficios cubre todos los beneficios esperados y lo ha
aprobado?
■■ confirmado que todos los miembros del equipo de gestión del proyecto han aceptado sus roles (la
estructura, los roles y responsabilidades del equipo de gestión del proyecto)?
■■ asegurado que los controles del proyecto sean adecuados para la naturaleza del proyecto?
 Apéndice E: Verificaciones | 319

Pregunta Sí/No
■■ asegurado que las necesidades de información y el calendario para comunicaciones, según la
definición en la Estrategia de Gestión de la Comunicación, sean adecuados para la naturaleza del
proyecto y la ha aprobado?
■■ revisado las tolerancias para el proyecto provistas por la gerencia corporativa o del programa a fin
de asegurar que sean apropiadas y realistas?
■■ considerado la uniformidad de los diversos componentes y aprobado la Documentación de Inicio
del Proyecto general?
19 La Junta de Proyecto, ¿ha informado a la gerencia corporativa o del programa (y a otras partes
interesadas) que el proyecto ha sido autorizado?

E.2.3 Autorizar un Plan de la Fase o un Plan de Excepción

Pregunta Sí/No
20 La Junta de Proyecto, ¿ha revisado el Informe al Final de Fase? Específicamente:
■■ ¿Revisó la junta el estado de desarrollo del proyecto utilizando el Informe al Final de Fase para la
fase de gestión actual?
■■ ¿Ha revisado la junta los beneficios logrados y las lecciones aprendidas durante la fase?
21 La Junta de Proyecto, ¿ha evaluado la viabilidad del proyecto en general? Específicamente, ¿ha:
■■ revisado el Plan de Proyecto y la posición en relación a las tolerancias del proyecto acordadas con la
gerencia corporativa o del programa?
■■ revisado el Business Case para asegurar que el proyecto todavía se justifique?
■■ revisado los riesgos principales para asegurar que el nivel de exposición todavía sea aceptable y que
haya acciones de respuesta planificadas?
■■ obtenido decisiones externas al proyecto para cualquier desviación posible más allá de las
tolerancias del proyecto? (Por ejemplo, si este proyecto es parte de un programa, entonces la
gerencia del programa debería haber examinado el impacto en el programa y tomado medidas
apropiadas).
22 La Junta de Proyecto, ¿ha revisado y aprobado el Plan de la Fase (o Plan de Excepción) siguiente?
Específicamente, ¿ha:
■■ revisado el plan para el cual el Project Manager solicita aprobación? (Éste será un Plan de la Fase
para la fase de gestión siguiente o un Plan de Excepción).
■■ autorizado al Project Manager a proceder con el plan presentado (Plan de la Fase o Plan de
Excepción) o ha dado instrucciones al Project Manager para el cierre prematuro del proyecto?
■■ fijado las tolerancias para la fase de gestión siguiente o (en el caso de un Plan de Excepción)
revisado las tolerancias de fase corrientes si es necesario?
23 La Junta de Proyecto, ¿ha informado a la gerencia corporativa o del programa (y a otras partes
interesadas) que la fase siguiente ha sido autorizada (o que se ha aprobado un Plan de Excepción para
la fase actual)?
320 | Apéndice E: Verificaciones

E.2.4 Dirección ad hoc

Pregunta Sí/No
24 La Junta de Proyecto, ¿ha respondido a las solicitudes del Project Manager? Específicamente, ¿ha:
■■ revisado la solicitud? (Ésta podría ser informal o formal; ésta última bajo la forma de un Informe de
Cuestiones).
■■ tomado una decisión - por ejemplo, aprobado, rechazado, diferido la decisión, solicitado más
información?
■■ dado orientación al Project Manager?
25 La Junta de Proyecto, ¿ha respondido a los informes? Específicamente, ¿ha:
■■ revisado el Informe de Desarrollo más reciente a fin de comprender el estado del proyecto y se
ha satisfecho, a través de diálogo con el Project Manager, de que la fase está progresando de
conformidad con el plan?
■■ tomado decisiones sobre los Informes de Excepción – ajustado las tolerancias o aprobado
respuestas a la excepción según sea apropiado?
■■ tomado decisiones sobre los Informes de Cuestiones dentro de los límites de autoridad delegados
por la junta o solicitado asesoramiento de la gerencia corporativa o del programa?
26 La Junta de Proyecto, ¿ha respondido a influencias externas? Específicamente, ¿ha:
■■ asegurado que se mantenga al proyecto al corriente de eventos externos que podrían afectar al
mismo?
■■ asegurado que el proyecto continúe estando centrado en los objetivos corporativos o del programa
fijados y que todavía se justifique en términos comerciales?
■■ asegurado que se notifique al Project Manager cualquier cambio en el entorno corporativo o del
programa que pueda tener un impacto en el proyecto y que se tomen medidas apropiadas?
27 La Junta de Proyecto, ¿ha informado a la gerencia corporativa o del programa (y a otras partes
interesadas) el progreso del proyecto de conformidad con la Estrategia de Gestión de la Comunicación?

E.2.5 Autorizar el cierre del proyecto

Pregunta Sí/No
28 La Junta de Proyecto, ¿ha confirmado la entrega y la aceptación? Específicamente, ¿ha:
■■ verificado que la entrega del producto del proyecto se haya hecho de conformidad con la Estrategia
de Gestión de la Configuración y, en particular, que exista la documentación relativa a todas las
aceptaciones por el usuario y de todas las aceptaciones de uso y mantenimiento requeridas?
■■ asegurado que, cuando sea apropiado, los cambios resultantes en el negocio sean apoyados y
sostenibles?
■■ asegurado que cualquier expectativa de calidad del cliente que no se puede confirmar hasta
después de que el proyecto se cierre (por ej. niveles de rendimiento en cuanto a fiabilidad) se
incluyan en el Plan de Revisión de Beneficios como un control post-proyecto?
29 La Junta de Proyecto, ¿ha aprobado el Informe al Final de Proyecto? Específicamente, ¿ha:
■■ utilizado la versión de la Documentación de Inicio del Proyecto que fue aprobada al iniciarse el
proyecto como la baseline para evaluar la manera en que el proyecto se ha desviado de su base
inicial y para proporcionar información con la cual juzgar el éxito del proyecto?
■■ asegurado que las acciones a realizar recomendadas se hayan registrado correctamente en el
Informe al Final de Proyecto y que se haya notificado a los grupos apropiados su responsabilidad de
llevarlas adelante?
 Apéndice E: Verificaciones | 321

Pregunta Sí/No
■■ aprobado el Informe al Final de Proyecto para distribución a cualquier parte interesada, tal como la
gerencia corporativa o del programa?
30 La Junta de Proyecto, ¿ha revisado el Informe sobre las Lecciones y acordado quién debería recibirlo?
La Junta, ¿ha asegurado que los grupos apropiados (por ejemplo, gerencia corporativa o del programa,
centro de excelencia) hayan sido notificados de su responsabilidad de llevar adelante cualquier
recomendación?
31 La Junta de Proyecto, ¿ha confirmado el Business Case? Específicamente, ¿ha confirmado el Business
Case actualizado al comparar beneficios, costes y riesgos actuales con los previstos en el Business
Case aprobado en la Documentación de Inicio del Proyecto? (Podría no ser posible confirmar todos los
beneficios ya que algunos no se concretarán hasta después del cierre del proyecto).
32 La Junta de Proyecto, ¿ha aprobado el Plan de Revisión de Beneficios actualizado? Específicamente,
¿ha:
■■ revisado y obtenido aprobación para el Plan de Revisión de Beneficios actualizado, asegurando que
aborde los beneficios esperados que todavía no pueden ser confirmados?
■■ confirmado que la responsabilidad del Plan de Revisión de Beneficios ha sido transferida a la
gerencia corporativa o del programa?
33 La Junta de Proyecto, ¿ha expedido la notificación de cierre del proyecto? Específicamente, ¿ha:
■■ revisado y expedido una notificación de cierre del proyecto de conformidad con la Estrategia de
Gestión de la Comunicación?
■■ informado a aquellos que suministraron la infraestructura de apoyo y recursos para el proyecto que
éstos se pueden retirar ahora?
■■ liberado los recursos suministrados al proyecto?
■■ dado una fecha de cierre para cargar costes al proyecto?

E.3 Inicio de un Proyecto

Pregunta Sí/No
34 ¿Se han identificado y, donde sea apropiado, aplicado las lecciones de proyectos similares anteriores?
35 ¿Se ha definido y documentado la Estrategia de Gestión del Riesgo?
36 ¿Se ha establecido y cumplimentado el Registro de Riesgos?
37 ¿Se ha definido y documentado la Estrategia de Gestión de la Configuración?
38 ¿Se han establecido las Fichas de Elementos de Configuración iniciales?
39 ¿Se ha establecido y cumplimentado el Registro de Cuestiones?
40 ¿Se ha definido y documentado la Estrategia de Gestión de la Calidad?
41 ¿Se ha establecido y cumplimentado el Registro de Calidad?
42 ¿Se ha definido y documentado la Estrategia de Gestión de la Comunicación?
43 ¿Se han determinado y establecido los controles del proyecto?
44 ¿Se ha creado el Plan de Proyecto?
45 ¿Se ha actualizado la estructura del equipo de gestión del proyecto de modo tal que refleje cualquier
rol nuevo que se designe o cualquier cambio en responsabilidades para los roles existentes?
46 Para nombramientos nuevos, ¿existen descripciones de roles y ha confirmado su aceptación la gente
que ha sido nombrada?
47 ¿Se ha perfeccionado el Business Case a fin de obtener un Business Case detallado?
48 ¿Se ha creado el Plan de Revisión de Beneficios (esto podría haber sido hecho por la gerencia
corporativa o del programa)?
322 | Apéndice E: Verificaciones

Pregunta Sí/No
49 ¿Se ha preparado la Documentación de Inicio del Proyecto?

E.4 Control de una Fase

Pregunta Sí/No
50 ¿Se han creado y entregado los Paquetes de Trabajo?
51 ¿Han aceptado todos los Team Managers todos sus Paquetes de Trabajo?
52 ¿Se han producido productos completados de conformidad con el Paquete de Trabajo y la Descripción
de Producto?
53 ¿Se han creado/actualizado las Fichas de Elementos de Configuración pertinentes?
54 ¿Se ha mantenido el Registro de Calidad?
55 ¿Se entregó algún producto como parte de una entrega escalonada? De ser así, ¿se entregó de
conformidad con la Estrategia de Gestión de la Configuración?
56 ¿Se ha mantenido el Registro de Riesgos?
57 ¿Se ha mantenido el Registro de Cuestiones?
58 ¿Se ha actualizado el Plan de la Fase con datos reales y las previsiones revisadas?
59 ¿Se ha mantenido el Archivo Diario?
60 ¿Se han recibido Informes del Punto de Control para cada Paquete de Trabajo entregado con la
frecuencia y en el formato convenidos?
61 ¿Se comparó el progreso (real y previsto) con las tolerancias acordadas?
62 Si se previó que se excederían las tolerancias, ¿se presentó una excepción a la Junta de Proyecto?
63 Si se requirieron rectificaciones, ¿se archivaron, implementaron y se les dio seguimiento?
64 ¿Se comprobó periódicamente la viabilidad continua del Business Case?
65 ¿Se crearon y entregaron Informes de Desarrollo de acuerdo con el formato y con la frecuencia para
presentación de informes convenidos?
66 ¿Existen Informes de Cuestiones para todas las cuestiones que se están manejando formalmente?
67 ¿Existen Informes de Excepción para todas las excepciones presentadas a la Junta de Proyecto?
68 ¿Se ha actualizado el Archivo sobre las Lecciones con cualquier lección nueva?

E.5 Gestión de la Entrega de Productos

Pregunta Sí/No
69 El Paquete de Trabajo y la o las Descripciones de Producto, ¿contienen suficiente información,
incluyendo referencias cruzadas, para permitir al Team Manager producir los productos requeridos?
70 ¿Se ha creado un Plan del Equipo que demuestra que el Paquete de Trabajo se podría completar
dentro de las tolerancias convenidas?
71 ¿Se ha actualizado el Plan del Equipo con información real y las previsiones revisadas?
72 ¿Se comparó el progreso (real y previsto) con las tolerancias acordadas?
73 Si se previó que se excederían las tolerancias, ¿se presentó una excepción al Project Manager?
74 ¿Se entregaron Informes del Punto de Control al Project Manager con la frecuencia y en el formato
convenidos?
75 ¿Comunicó el Team Manager alguna cuestión y riesgo al Project Manager?
76 ¿Existe documentación para cada producto completado?
 Apéndice E: Verificaciones | 323

Pregunta Sí/No
77 ¿Comunicó el Team Manager a Apoyo al Proyecto cualquier actualización requerida a la Ficha de un
Elemento de Configuración y al Registro de Calidad?
78 ¿Comunicó el Team Manager al Project Manager que todos los productos en el Paquete de Trabajo
habían sido entregados?

E.6 Gestión de los Límites de Fase

Pregunta Sí/No
79 ¿Se han aprobado todos los productos que se había planificado que se terminarían dentro de la fase?
80 ¿Se ha creado un informe sobre el estado de los productos para verificar el estado de los productos de
la fase?
81 ¿Si hubo una entrega de producto durante la fase, ¿se documentaron las cuestiones pendientes
relacionadas como acciones a realizar recomendadas listas para la distribución, con sujeción a la
aprobación de la Junta de Proyecto?
82 ¿Se ha revisado y actualizado el Archivo sobre las Lecciones?
83 Si se requiere, ¿se ha creado un Informe sobre las Lecciones listo para distribución, con sujeción a la
aprobación de la Junta de Proyecto?
84 ¿Se ha actualizado el Plan de la Fase con información real?
85 ¿Se ha revisado la Estrategia de Gestión del Riesgo y (si es necesario) actualizado?
86 ¿Se ha revisado y actualizado el Registro de Riesgos?
87 ¿Se ha revisado la Estrategia de Gestión de la Configuración y (si es necesario) actualizado?
88 ¿Se han revisado y actualizado las Fichas de Elementos de Configuración?
89 ¿Se ha revisado y actualizado el Registro de Cuestiones?
90 ¿Se ha revisado la Estrategia de Gestión de la Calidad y (si es necesario) actualizado?
91 ¿Se ha revisado y actualizado el Registro de Calidad?
92 ¿Se ha revisado la Estrategia de Gestión de la Comunicación y (si es necesario) actualizado?
93 ¿Se han revisado los controles del proyecto y (si es necesario) actualizado?
94 ¿Se ha revisado el Plan de Proyecto y (si es necesario) actualizado?
95 ¿Se ha actualizado la estructura del equipo de gestión del proyecto de modo tal que refleje cualquier
rol nuevo que se designe o cambios en responsabilidades para los roles existentes?
96 Para nombramientos nuevos, ¿existen descripciones de roles y ha confirmado su aceptación la gente
que ha sido nombrada?
97 ¿Se ha revisado el Business Case y (si es necesario) actualizado?
98 ¿Se ha revisado el Plan de Revisión de Beneficios y (si es necesario) actualizado?
99 ¿Se ha revisado la Documentación de Inicio del Proyecto y (si es necesario) actualizado?
100 ¿Se ha producido un Informe al Final de Fase que muestre el desarrollo real comparado con el
desarrollo planificado y con un resumen de las lecciones y las acciones a realizar recomendadas?
101 ¿Se ha entregado el Informe al Final de Fase a la Junta de Proyecto de conformidad con los controles
del proyecto?
Para la fase siguiente
102 ¿Se ha creado el Plan de la Fase siguiente?
103 ¿Se han creado Descripciones de Productos para los productos de la fase siguiente?
104 ¿Se ha solicitado a la Junta de Proyecto que autorice la fase siguiente?
324 | Apéndice E: Verificaciones

Pregunta Sí/No
Para las excepciones
105 ¿Se ha creado un Plan de Excepción (si ha sido solicitado por la Junta de Proyecto)?
106 ¿Se han creado/actualizado las Descripciones de Productos para el Plan de Excepción?
107 ¿Se ha solicitado a la Junta de Proyecto que apruebe el Plan de Excepción?

E.7 Cierre de un Proyecto

Pregunta Sí/No
108 ¿Se han completado y aprobado todos los productos?
109 ¿Se ha creado un informe sobre el estado de los productos para verificar el estado de todos los
productos?
110 ¿Se han documentado todas las cuestiones pendientes como acciones a realizar recomendadas listas
para distribución, con sujeción a la aprobación de la Junta de Proyecto?
111 Para un cierre prematuro, ¿ha aprobado la Junta de Proyecto los medios para la recuperación de los
productos que se han completado o que se están desarrollando? Si se solicitó, ¿se creó y aprobó un
Plan de Excepción?
112 ¿Hay documentación de aceptación para la entrega del producto del proyecto?
113 La documentación de aceptación, ¿incluye aceptación de uso y mantenimiento?
114 ¿Se ha revisado el Archivo sobre las Lecciones y se ha creado un Informe sobre las Lecciones listo para
distribución, con sujeción a la aprobación de la Junta de Proyecto?
115 ¿Se ha actualizado el Plan de Proyecto con datos reales?
116 ¿Se ha actualizado el Business Case con datos reales?
117 ¿Se ha actualizado el Plan de Revisión de Beneficios con datos reales?
118 ¿Se ha producido un Informe al Final de Proyecto que muestre el desarrollo real comparado con el
desarrollo planificado y con un resumen de las lecciones y las acciones a realizar recomendadas?
119 ¿Se ha entregado el Informe al Final de Proyecto a la Junta de Proyecto de conformidad con los
controles del proyecto?
120 ¿Se ha creado un borrador de la notificación de cierre del proyecto para aprobación por la Junta de
Proyecto y para entrega posterior?
121 ¿Se han cerrado todos los registros y archivos?
122 ¿Se ha archivado toda la documentación del proyecto?

 Apéndice F:
Diccionario de términos F
Apéndice F: Diccionario de términos

En esta sección se incluyen, de forma esquemática, F.2 PROCESOS y ACTIVIDADES

todos los términos específicos que se utilizan en
En este listado se encuentran los procesos y las
esta publicación y su original en inglés.
actividades que se detallan en los capítulos 11-18

F.1 Principios Versión original Traducción

Starting up a project Puesta en Marcha
En este listado se encuentran los nombres de los
de un Proyecto
principios de PRINCE2, detallados en el capítulo 2
Appointing the Executive Nombrar al Ejecutivo y al
Versión original Traducción and the Program Manager Project Manager
Continued business Justificación comercial Capture previous lessons Registrar lecciones anteriores
justification continua Design and appoint the Diseñar y nombrar al equipo
Learn from experience Aprender de la experiencia project management team de gestión del proyecto
Defined roles and Roles y responsabilidades Prepare the outline Business Preparar el Business Case
responsibilities definidos Case preliminar
Manage by stage Gestión por fases Select the project approach Seleccionar el enfoque
Manage by exception Gestión por excepción and assemble the Project del proyecto y elaborar el
Focus on products Enfoque en los productos Brief Expediente del Proyecto
Tailor to suit the environment Adaptación para Plan the initiation stage Planificar la fase de inicio
corresponder al
entorno del proyecto Directing a Project Dirección de un Proyecto
Authorise initiation Autorizar el inicio
Authorise the project Autorizar el proyecto
Authorise a Stage or Autorizar un Plan de la Fase
F.2 TEMÁTICAS
Exception Plan o de Excepción
En este listado se encuentran los títulos de las Give ad hoc direction Proporcionar dirección
temáticas tratadas en los capítulos 3-10 ad hoc
Versión original Traducción Authorise project closure Autorizar el cierre del
Business Case Business Case proyecto

Organization Organización
Quality Calidad Initiating a Project Inicio de un Proyecto

Plans Planes Prepare the Risk Preparar la Estrategia de

Management Strategy
Risk Riesgo
Prepare the Configuration
Change Cambio
Management Strategy
Progress Progreso
Prepare the Quality
Management Strategy
Prepare the Communication
Management Strategy
Set up the project controls
Create the Project Plan
Refine the Business Case
Assemble the Project
Initiation Documentation
Gestión del Riesgo
Preparar la Estrategia de
Gestión de la Configuración
Preparar la Estrategia de
Gestión de la Calidad
Preparar la Estrategia de
Gestión de la Comunicación
Establecer los controles del
proyecto
Crear el Plan de Proyecto
Perfeccionar el Business Case
Preparar la Documentación
de Inicio del Proyecto
328 | Apéndice F: Diccionario de términos
Versión original
Controlling a Stage
Authorise a Work Package
Review Work Package status
Receive completed Work
Packages
Review the stage status
Report highlights
Capture and Examine issues
and risks
Escalating issues and risks
Take corrective action
Managing Product
Delivery
Accept a Work Package
Execute a Work Package
Deliver a Work package
Managing a Stage
Boundary
Plan the Next Stage
Update the Project Plan
Update the Business Case
Report stage end
Produce an Exception Plan
Closing a Project
Prepare Planned Closure
Prepare Premature Closure
Hand Over Products
Evaluate the Project
Recommend Project Closure
Traducción
Control de una Fase
Autorizar un Paquete de
Trabajo
Revisar el estado del Paquete
de Trabajo
Recibir el Paquete de Trabajo
completado
Revisar el estado de la fase
Informar sobre el desarrollo
Registrar y examinar
cuestiones y riesgos
Presentar excepciones
relativas a cuestiones y
riesgos
Llevar a cabo rectificaciones
Gestión de la Entrega de
Productos
Aceptar un Paquete de
Trabajo
Ejecutar un Paquete de
Trabajo
Entregar un Paquete de
Trabajo
Gestión de los Límites de
Fase
Planificar la fase siguiente
Actualizar el Plan de
Proyecto
Actualizar el Business Case
Informar sobre el final de la
fase
Elaborar un Plan de
Excepción
Cierre de un Proyecto
Preparar el cierre planificado
Preparar el cierre prematuro
Entregar los productos
Evaluar el proyecto
Recomendar el cierre del
proyecto
F.4 PRODUCTOS DE GESTIón PRINCE2
En este listado se encuentra el nombre de todos
los productos de gestión sugeridos por PRINCE2.
Para la descripción del contenido básico de cada
producto véase el apéndice A.
Versión original Traducción
A1 Benefits Review Plan A.23 Plan de Revisión de
Beneficios
A2 Business Case A.3 Business Case
A3 Checkpoint Report A.18 Informe del Punto de
Control
A4 Communication A.8 Estrategia de Gestión de
Management Strategy la Comunicación
A5 Configuration Item A.12 Ficha de un Elemento
Record de Configuración
A6 Configuration A.9 Estrategia de Gestión de
Management Strategy la Configuración
A7 Daily Log A.2 Archivo Diario
A8 End Project Report A.14 Informe al Final de
Proyecto
A9 End Stage Report A.13 Informe al Final de Fase
A10 Exception Report A.17 Informe de Excepción
A11 Highlight Report A.16 Informe de Desarrollo
A12 Issue Register A.25 Registro de Cuestiones
A13 Issue Report A.15 Informe de Cuestiones
A14 Lessons Log A.1 Archivo sobre las
Lecciones
A15 Lessons Report A.20 Informe sobre las
Lecciones
A16 Plan A.22 Plan
A17 Product Description A.4 Descripción de Producto
A18 Product Status Account A.19 Informe sobre el Estado
de los Productos
A19 Project Brief A.11 Expediente del Proyecto
A20 Project Initiation A.6 Documentación de Inicio
Document del Proyecto
A21 Project Product A.5 Descripción del Producto
Description del Proyecto
A22 Quality Management A.7 Estrategia de Gestión de
Strategy la Calidad
A23 Quality Register A.24 Registro de Calidad
A24 Risk Management A.10 Estrategia de Gestión
Strategy del Riesgo
A25 Risk Register A.26 Registro de Riesgos
A26 Work Package A.21 Paquete de Trabajo
 Apéndice F: Diccionario de términos | 329

F.5 ROLES Versión original Traducción

En este listado se encuentran los roles corporate or programme normas corporativas o del
contemplados por PRINCE2 y detallados en el standards programa
Apéndice C. corrective action rectificación
customer cliente
Versión original Traducción
customer’s quality expectativas de calidad del
Project Board Junta de Proyecto
expectations cliente
Executive Ejecutivo
deliverable producto a entregar
Senior User Usuario Principal
dependencies (plan) dependencias (plan)
Senior Supplier Proveedor Principal
dis-benefit contrabeneficio
Project Manager Project Manager
embedding (PRINCE2) adopción (PRINCE2)
Team Manager Team Manager
end stage assessment Evaluación al Final de Fase
Project Assurance Garantía del Proyecto
enhance (risk response) incrementar (respuesta al
Change Authority Autoridad de Cambios
riesgo)
Project Support Apoyo al Proyecto
event-driven control control basado en eventos
exception excepción
exception assessment evaluación de excepción
F.6 TÉRMINOS DE GLOSARIO exploit (risk response) aprovechar (respuesta al
riesgo)
En este listado se encuentran los términos que
fallback (risk response) estrategia alternativa
aparecen en el glosario.
(respuesta al riesgo)
Versión original Traducción
follow-on action acciones a realizar
accept (risk response) aceptar (respuesta al riesgo)
recommendations recomendadas
acceptance aceptación
governance (corporate) gobierno (corporativo)
acceptance criteria criterios de aceptación
handover entrega
activity actividad
host site sede
approval aprobación
impact (of risk) impacto (de riesgo)
approver aprobador
inherent risk riesgo inherente
assumption suposición
initiation stage fase de inicio
authority autoridad
issue cuestión
authorization autorización
management product producto de gestión
avoid (risk response) evitar (respuesta al riesgo)
management stage fase de gestión
baseline baseline
milestone hito
baseline management versión baseline (producto
off-specification fuera de especificación
product de gestión)
operational and maintenance aceptación de uso y
benefit beneficio
acceptance mantenimiento
benefits tolerance tolerancia de beneficios
outcome resultado final
centre of excellence centro de excelencia
output resultado
change budget presupuesto para cambios
performance targets metas de rendimiento
change control control de cambios
plan plan
checkpoint punto de control
planned closure cierre planificado
closure notification notificación de cierre
planning horizon horizonte de planificación
closure recommendation recomendación de cierre
portfolio cartera
concession concesión
premature closure cierre prematuro
configuration item elemento de configuración
prerequisites (plan) prerrequisitos (plan)
configuration management gestión de la configuración
probability probabilidad
constraints restricciones
330 | Apéndice F: Diccionario de términos

Versión original Traducción Versión original Traducción

problem/concern problema/asunto risk appetite propensión al riesgo
procedure procedimiento risk estimation estimación de riesgo
process proceso risk evaluation evaluación de riesgo
producer productor risk management gestión del riesgo
product producto risk owner propietario del riesgo
product breakdown structure estructura jerárquica de risk profile perfil de riesgo
productos risk response respuesta al riesgo
product checklist lista de productos risk response category categoría de respuesta al
product flow diagram diagrama de flujo de los riesgo
productos risk tolerance line línea de tolerancia del riesgo
product-based planning planificación basada en el role description descripción del rol
producto schedule cronograma
programme programa scope alcance
project approach enfoque del proyecto Senior Responsible Owner Propietario Responsable
project authorization notificación de autorización (SRO) Principal (SRO)
notification del proyecto share (risk response) compartir (respuesta al
project initiation notification notificación de inicio del riesgo)
proyecto specialist product producto especializado
project lifecycle ciclo de vida del proyecto sponsor patrocinador
project management team estructura del equipo de stage fase
structure gestión del proyecto
Stage Plan Plan de la Fase
project mandate mandato de proyecto
stakeholder parte interesada
project office oficina de proyecto
start up puesta en marcha
project product producto del proyecto
supplier proveedor
proximity (of risk) proximidad (del riesgo)
tailoring adaptación
quality assurance garantía de calidad
technical stage fase técnica
quality control control de calidad
time-driven control control basado en tiempo
quality criteria criterios de calidad
tolerance tolerancia
quality inspection inspección de calidad
transfer (risk response) transferir (respuesta al
quality management gestión de la calidad riesgo)
quality management system sistema de gestión de la trigger desencadenante
calidad
user acceptance aceptación por el usuario
quality records testimonios documentales de
user usuario
calidad
variant variante
quality review revisión de calidad
version versión
records testimonios documentales
reduce (risk response) reducir (respuesta al riesgo)
registers registros
reject (risk response) rechazar (respuesta al riesgo)
release release
reports informes
request for change solicitud de cambio
residual risk riesgo residual
reviewer revisor
risk actionee ejecutor de riesgo
Información adicional
Información adicional
De la Oficina de Comercio
Gubernamental del Reino Unido
PRINCE2
PRINCE2 forma parte de un conjunto de
orientaciones desarrolladas por la Oficina de
Comercio Gubernamental del Reino Unido
(OGC), destinado a ayudar a organizaciones y
particulares a gestionar sus proyectos, programas y
servicios. En la medida en que se estima oportuno,
estas orientaciones cuentan con el apoyo de
un programa de cualificaciones y de servicios
acreditados de capacitación y asesoría.
Éxito en la Gestión de Proyectos con PRINCE2
(2009). The Stationery Office, Londres.
Directing Successful Projects with PRINCE2 (2009).
The Stationery Office, Londres.
Gestión del Riesgo
Los proyectos existen en un mundo
fundamentalmente incierto y, en consecuencia, la
gestión del riesgo efectiva es crucial para la gestión
de la entrega de los productos del proyecto, sus
resultados finales y los beneficios últimos que se
han identificado. La guía sobre Gestión del Riesgo
pone la gestión del riesgo del proyecto en el
contexto del entorno comercial más amplio.
Management of Risk: Guidance for Practitioners
(2007). The Stationery Office, Londres.
Éxito en la Gestión de Programas
Gestionar Programas con Éxito constituye una
buena práctica comprobada de gestión de
programas para entregar con éxito cambios
transformativos a una gran variedad de
organizaciones del sector público y del sector
privado. Proporciona un marco para dirigir y
controlar la implementación de un conjunto de
actividades y proyectos relacionados a fin de
entregar los resultados finales y los beneficios
relacionados con los objetivos estratégicos de la
organización.
Managing Successful Programmes (2007). The
Stationery Office, Londres.
Guía de Gestión de Carteras
La Guía de Gestión de Carteras explica los
principios más importantes de la gestión de
carteras, tomando como base la experiencia de
organizaciones del sector público y del sector
privado, tanto del Reino Unido como en el ámbito
internacional. Proporciona consejos prácticos sobre
el establecimiento de una función de gestión de
carteras, ilustrados con ejemplos reales, y concluye
con una sección con consejos y orientación
adicionales. Los principales destinatarios de
esta guía incluyen a los equipos responsables de
coordinar programas y proyectos, especialmente
a quienes proporcionan apoyo para decisiones
de inversión y rinden cuentas sobre el progreso a
la junta directiva. Se presupone un conocimiento
razonable de gestión de programas y proyectos y
de información sobre el progreso.
Modelo de Madurez de Gestión de
Proyectos, Programas y Carteras (P3M3™)
El Modelo de Madurez de Gestión de Proyectos,
Programas y Carteras (P3M3) es una guía
de referencia sobre las mejores prácticas
estructuradas. Divide las disciplinas generales de
gestión de proyectos, programas y carteras en una
jerarquía de perspectivas.
El enfoque jerárquico permite a las organizaciones
evaluar su capacidad actual y diseñar una hoja
de ruta para mejoras ordenadas por prioridad en
base a aquellas perspectivas que tendrán el mayor
impacto sobre el rendimiento.
Oficinas de Proyecto, Programa y Cartera
(P3O)
La guía de Oficinas de Proyecto, Programa y
Cartera proporciona orientación sobre cómo
definir, establecer y operar una oficina de proyecto,
programa o cartera. Cubre las distintas funciones y
servicios que dichas oficinas pueden proporcionar
e incluye referencias a las técnicas que se pueden
emplear.
Portfolio, Programme and Project Offices (2008).
The Stationery Office, Londres.
334 | Información adicional
El Modelo de Madurez de PRINCE2
(P2MM)
El Modelo de Madurez de PRINCE2 describe un
conjunto de áreas de proceso principales requeridas
para la implementación y el uso de manera eficaz
de PRINCE2 dentro de una organización. Este es
el valor principal de P2MM: si bien el manual de
PRINCE2 describe cómo gestionar un solo proyecto,
no incluye ningún proceso sobre cómo adoptar
PRINCE2, mientras que P2MM lo incluye.
P2MM describe actividades principales en línea
con los procesos y componentes de PRINCE2 para
posibilitar la aplicación repetible del método (Nivel
2), y va más allá al describir las prácticas principales
requeridas para institucionalizar el método (Nivel
3) como proceso comercial estándar para la gestión
de proyectos.
Revisión Gateway de la OGC
El proceso de la Revisión Gateway de la OGC es
un reconocido proceso de revisión de garantía
de proyectos y programas que se ordena para
todos los programas y proyectos de alto riesgo del
gobierno del Reino Unido. La Revisión Gateway
de la OGC proporciona una revisión de expertos,
en la que profesionales independientes externos
al programa/proyecto específico utilizan su
experiencia y conocimientos para examinar el
progreso y evaluar la probabilidad de una entrega
con éxito del programa o del proyecto. El proceso
de revisión se utiliza para proporcionar una
valiosa perspectiva adicional de las cuestiones que
afronta el equipo interno, y un desafío externo
a la solidez de los planes y procesos. Este servicio
se basa en buenas prácticas y existen en todos los
sectores comerciales muchos ejemplos similares de
este tipo de revisión de expertos diseñada para
proporcionar garantía al propietario del programa
o del proyecto.
Se puede obtener información completa sobre el
proceso de la Revisión Gateway de la OGC en el
sitio web de la propia OGC.
Lograr la Excelencia en la Construcción
La orientación de contratación pública sobre Lograr
la Excelencia en la Construcción está compuesta
por un conjunto de once manuales y dos guías de
alto nivel. Se basa en la experiencia reciente de
los distintos departamentos del gobierno central
británico, sirve de apoyo a futuras estrategias y
está en línea con el proceso de Revisión Gateway
de la OGC.
Mediante la iniciativa de Lograr la Excelencia en
la Construcción, los departamentos del gobierno
central y las organizaciones del sector público se
comprometen a maximizar, mediante mejoras
continuas, la eficacia, la eficiencia y la relación
calidad-precio de sus contratos para la realización
de obras nuevas, obras de mantenimiento y obras
de restauración.
ITIL Service Management - Prácticas de
Gestión de Servicios ITIL®
ITIL es el enfoque más aceptado en el mundo
para la gestión de servicios de tecnología de la
información. Proporciona un conjunto unido de
orientaciones sobre las mejores prácticas, extraídas
de los sectores público y privado de todo el mundo,
y recientemente se ha sometido a un amplio e
importante proyecto de puesta al día.
La Gestión de Servicios de Tecnología de la
Información (ITSM) se beneficia enormemente
de un enfoque basado en las mejores prácticas.
Como ITSM se basa tanto en tecnología como en la
enorme variedad de entornos organizativos en los
que opera, se encuentra en un estado de evolución
constante. Las mejores prácticas, basadas en
asesoramiento de expertos y aportes de usuarios de
ITIL, son tanto actuales como útiles, y combinan las
ideas más novedosas con una orientación sensata,
que atiende al sentido común.
Continual Service Improvement (2007).
The Stationery Office, Londres.
Service Design (2007).
The Stationery Office, Londres.
Service Operation (2007).
The Stationery Office, Londres.
Service Strategy (2007).
The Stationery Office, Londres.
Service Transition (2007).
The Stationery Office, Londres.

Publicaciones complementarias de
The Stationery Office
APMP para Profesionales de PRINCE2
Esta guía de estudio permite a los candidatos que
están familiarizados con PRINCE2 prepararse para
el examen de APMP. Proporciona a los candidatos
del examen de APMP una única fuente de material
de referencia que abarca todos los aspectos del
programa de estudios de APMP, incluyendo tanto
material previo al curso como material para el
curso, manteniéndolo en línea con el método
de PRINCE2. Esto permite a los profesionales de
PRINCE2 (o al personal de gestión de proyectos que
trabaja dentro de un entorno de PRINCE2) ampliar
sus conocimientos de gestión de proyectos para
cubrir todos los temas del programa de estudios de
APMP.
APMP for PRINCE2 Practitioners (2008). The
Stationery Office, Londres.
Focus on Skill - Serie de tres libros sobre
competencias
La serie explora las distintas competencias
relacionales que son propias de quienes gestionan
eficazmente proyectos y programas, ya que
los aspectos de la coordinación, motivación y
comunicación diarias de la gestión de proyectos y
programas son muy similares.
Leadership Skills for Project and Programme
Managers (2008). The Stationery Office, Londres.
Team Management Skills for Project and
Programme Managers (2008). The Stationery
Office, Londres.
Communication Skills for Project and Programme
Managers (2008). The Stationery Office, Londres.
Agile Project Management: Llevar a cabo
Proyectos de PRINCE2 con DSDM Atern
Esta innovadora publicación muestra cómo
los usuarios pueden combinar la fuerza de los
dos enfoques considerados, de modo que se
complementen entre sí para crear un nuevo marco
óptimo, adecuado para todos los entornos de
proyecto. Basada en PRINCE2 y en DSDM Atern,
los dos enfoques de gestión de proyectos más
utilizados y con mayor reconocimiento a nivel
internacional, esta obra explora las diferencias
entre los dos enfoques antes de mostrar en qué
Información adicional | 335
aspectos se sobreponen y cómo se pueden integrar.
Si bien DSDM Atern es una metodología de gestión
de proyectos de por sì, esta nueva publicación
se sitúa dentro de la serie de publicaciones de
PRINCE2.
Agile Project Management: Running PRINCE2
Projects with DSDM Atern (2007). The Stationery
Office, Londres.
PRINCE2 Maturity Model - Mejorar el
Rendimiento de los Proyectos utilizando
el Modelo de Madurez de PRINCE2
A menudo se hace referencia a PRINCE2 como el
método de gestión de proyectos más utilizado
en todo el mundo, pero, aunque el manual de
PRINCE2 describe cómo gestionar un proyecto en
particular, no incluye orientaciones acerca de cómo
adoptar PRINCE2 en una organización.
Ya está disponible esa orientación: esta publicación
describe las prácticas y los procesos organizativos
requeridos para la implementación eficaz de
PRINCE2 como norma organizativa. Incluye
orientación sobre la asignación de la propiedad,
la adaptación del método, la capacitación, la
integración de PRINCE2 con otros sistemas de
gestión y el establecimiento de mecanismos de
garantía de calidad para lograr una capacidad de
mejora continua.
Al leer la guía “Mejorar el Rendimiento de los
Proyectos utilizando el Modelo de Madurez de
PRINCE2”, descubrirá cómo las organizaciones
pueden sacar el mayor partido al método de
PRINCE2. Contiene consejos prácticos sobre el uso
del Modelo de Madurez de PRINCE2 (P2MM) de la
OGC y muestra cómo se puede aplicar el P2MM en
diferentes situaciones.
Improving Project Performance using the PRINCE2
Maturity Model (2007). The Stationery Office,
Londres.
336 | Información adicional

Otras fuentes
A continuación se incluye una lista de referencias
útiles, algunas de las cuales han sido citadas por los
autores de PRINCE2.
Adair, John (2004) The John Adair Handbook of
Management and Leadership, Thorogood, ISBN
978-1854182043.
APM GoPM Specific Interest Group (2005) Directing
Change: A Guide to the Governance of Project
Management, 2.a edición, Association for Project
Management, High Wycombe, ISBN 1-903494-15-X.
Association of Project Management (2006) APM
Body of Knowledge, 5.a edición, High Wycombe,
ISBN 978-1903494134.
British Standards Institution (2002) BS6079–1:2002
A Guide to Project Management, BSI, Londres.
Goldratt, Eliyahu M. (1997) Critical Chain, Avebury,
ISBN 978-0566080388.
International Project Management Association
(2006) ICB-IPMA Competency Baseline, version 3.0,
ISBN 0-9553213-0-1.
Project Management Institute (2004) A Guide to
the Project Management Body of Knowledge:
PMBOK Guide, 3.a edición, ISBN 978-1930699458.
Winter, Mark and Smith, Charles (2006) Rethinking
Project Management, EPSRC Network 2004–2006.
Glosario
Glosario
acciones a realizar recomendadas
Acciones recomendadas relacionadas con el trabajo sin
terminar, cuestiones y riesgos actuales y cualquier otra
actividad necesaria para llevar un producto a la próxima
fase de su vida. Se resumen y se incluyen en el Informe
al Final de Fase (para entrega por fases) y en el Informe
al Final de Proyecto.
aceptación alcance
El acto formal de reconocer que el proyecto ha cumplido
los criterios de aceptación acordados y así satisfecho las
exigencias de sus partes interesadas.
aceptación de uso y mantenimiento
Un tipo específico de aceptación por la persona o grupo
que apoyará el producto una vez que sea entregado al
entorno de operaciones.
aceptación por el usuario del proyecto, orientación, servicios administrativos tales
Un tipo específico de aceptación por la persona o el
grupo que utilizará el producto una vez entregado al
entorno operacional.
aceptar (respuesta al riesgo)
Una respuesta al riesgo frente a una amenaza
como resultado de la cual se toma, intencional y
deliberadamente, la decisión de retener la amenaza
al haberse constatado que es más económico hacer
esto que intentar una acción de respuesta al riesgo.
Se debería continuar haciendo el seguimiento de la
amenaza para asegurarse de que se mantenga tolerable.
actividad
Un proceso, una función o una tarea que ocurre durante
un tiempo, tiene resultados reconocibles y se gestiona.
Por lo general se define como parte de un proceso o de
un plan.
adaptación
Uso apropiado de PRINCE2 en cualquier proyecto dado,
asegurando el grado correcto de planificación, control,
gobierno y uso de los procesos y temáticas. (Por otra
parte, la decisión de implementar PRINCE2 a nivel
corporativo se conoce como ‘adopción).
adopción (PRINCE2)
Aquello que una organización necesita hacer para
implementar PRINCE2 como su método corporativo de
gestión del proyecto. Para contrastar, véase también
‘adaptación’ en tanto que ésta define aquello que
un proyecto debe hacer para aplicar el método a un
entorno de proyecto específico.
En un plan, se trata de la suma total de sus productos y
el nivel de sus requerimientos. El alcance se describe en
la estructura jerárquica de productos para el plan y las
Descripciones de Productos asociadas.
Apoyo al Proyecto
Un rol administrativo en el equipo de gestión del
proyecto. El Apoyo al Proyecto puede consistir en
asesoramiento y ayuda con las herramientas de gestión
como archivo y la recopilación de datos reales.
aprobación
La confirmación formal de que un producto está
completo y satisface sus requerimientos (menos
cualquier concesión) como se define mediante su
Descripción de Producto.
aprobador
La persona o el grupo (por ej. una Junta de Proyecto)
identificados como cualificados y autorizados para
aprobar un producto (de gestión o especializado) como
completo y apto para su propósito.
aprovechar (respuesta al riesgo)
Una respuesta al riesgo frente a una oportunidad en la
que ésta se aprovecha para asegurarse de que la misma
tenga lugar y que el impacto se concrete.
Archivo sobre las Lecciones
Un depósito informal para las lecciones que sean de
aplicación a este proyecto o a proyectos futuros.
340 | Glosario
Archivo Diario Business Case
Se utiliza para dejar constancia de problemas/asuntos
que pueden ser manejados informalmente por el Project
Manager.
archivos
Depósitos informales gestionados por el Project
Manager que no requieren ninguna aprobación
de la Junta de Proyecto en cuanto a su formato y
composición. PRINCE2 tiene dos archivos: el Archivo
Diario y el Archivo sobre las Lecciones.
Atern de DSDM especificaciones.
Un marco para entrega de proyectos Agile desarrollado
por el consorcio DSDM y propiedad del mismo. Atern
utiliza un enfoque con límites de tiempo e iterativo para
el desarrollo de productos y es compatible con PRINCE2.
autoridad
El derecho a asignar recursos y tomar decisiones
(aplicable a nivel de proyecto, fase y equipo).
Autoridad de Cambios
Una persona o grupo al cual la Junta de Proyecto puede
delegar responsabilidad para la consideración de las
solicitudes de cambios o variaciones de especificaciones
(fuera de especificación). La Autoridad de Cambios
puede llegar a contar con un presupuesto para cambios
y podrá aprobar cambios dentro de ese presupuesto.
autoridad responsable en los métodos y procesos, gestión de conocimientos,
La persona o grupo que encarga el proyecto
(generalmente la gerencia corporativa o del programa)
que tiene autoridad para asignar recursos y fondos en
nombre de la organización que encarga el proyecto.
autorización
El punto en el cual se otorga una autoridad.
baseline
Niveles de referencia en base a los cuales se realiza el
seguimiento y se controla una entidad.
beneficio Manager debe asegurarse de que el trabajo en curso
La mejora medible que se obtiene de un resultado
final, que es percibida como una ventaja por una o más
partes interesadas.
La justificación de una actividad de la organización
(proyecto) que típicamente contiene costes, beneficios,
riesgos y calendarios y en función de la cual se
comprueba la viabilidad continua.
calidad
La totalidad de los rasgos y las características inherentes
o asignadas a un producto, una persona, un proceso,
un servicio y/o un sistema que proporciona la capacidad
de demostrar que éste cumple las expectativas o
satisface necesidades declaradas, requerimientos o
cartera
Todos los programas y proyectos independientes que
una organización, un grupo de organizaciones o una
unidad organizativa están realizando.
categoría de respuesta al riesgo
Una categoría de respuesta al riesgo. Para las amenazas,
la categoría de respuesta al riesgo individual puede
ser evitar, reducir, transferir, aceptar o compartir. Para
las oportunidades, la categoría de respuesta al riesgo
individual puede ser aprovechar, incrementar, rechazar o
compartir.
centro de excelencia
Una función corporativa coordinadora para carteras,
programas y proyectos que facilita normas, uniformidad
garantías y capacitación.
ciclo de vida del proyecto
El período comprendido entre la puesta en marcha de
un proyecto y la aceptación del producto del proyecto.
cierre planificado
La actividad de PRINCE2 para cerrar un proyecto.
cierre prematuro
La actividad de PRINCE2 para cerrar un proyecto
con anterioridad a su cierre planificado. El Project
no sea sencillamente abandonado, sino que se rescate
cualquier valor creado hasta la fecha y que se controle
que cualquier discontinuidad, debida a la cancelación
del proyecto, se eleve a nivel corporativo o de gestión
del programa.

cliente control basado en tiempo
La persona o grupo de personas que han encargado el
trabajo y que se beneficiarán de los resultados finales.
compartir (respuesta al riesgo)
Una respuesta al riesgo tanto para una amenaza como
para una oportunidad mediante la aplicación de una
fórmula de perjuicio/beneficio: ambas partes comparten
el beneficio (dentro de límites previamente acordados)
si el coste de la respuesta es menor que el coste
planificado; y comparten el perjuicio (de nuevo, dentro
de límites acordados previamente) si se excede el coste
planificado.
concesión control de cambios
Un fuera de especificación aceptado por la Junta de
Proyecto sin ninguna rectificación.
contingencia objetivos acordados para el proyecto.
Algo que se mantiene en reserva, normalmente, para
manejar variaciones en tiempo y costes o riesgos.
PRINCE2 no es partidario de utilizar contingencias ya
que las variaciones en estimaciones se gestionan fijando
tolerancias.
Los riesgos se gestionan a través de respuestas a riesgos
apropiadas (incluida la respuesta de la estrategia
alternativa que está sujeta a que el riesgo ocurra).
contrabeneficio Una descripción de la especificación de calidad que el
Resultado final percibido como negativo por una o
más partes interesadas. Es una consecuencia cierta de
una actividad, mientras que, por definición, un riesgo
presenta un nivel de incertidumbre acerca de si se va a
concretar.
control basado en eventos
Un control que se aplica cuando ocurre un evento
específico. Esto podría ser, por ejemplo, el final de una
fase, haber rellenado la Documentación de Inicio del
Proyecto o la creación de un Informe de Excepción.
También podría incluir eventos de organización que
podrían afectar al proyecto, tal como el final del año
fiscal.
Glosario | 341
Controles que son periódicos para permitir que
la autoridad inmediatamente superior realice el
seguimiento del progreso; por ejemplo, un control
que tiene lugar cada 2 semanas. PRINCE2 ofrece dos
informes de progreso clave basados en el tiempo: el
Informe del Punto de Control y el Informe de Desarrollo.
control de calidad
El proceso de realizar el seguimiento de resultados
específicos del proyecto para determinar si cumplen con
las normas pertinentes e identificar maneras de eliminar
las causas de niveles de servicio no satisfactorios.
El procedimiento que asegura que se identifiquen, se
evalúen y que o bien se aprueben, se rechacen o se
posterguen todos los cambios que puedan afectar los
criterios de aceptación
Una lista priorizada de criterios que el producto del
proyecto debe satisfacer para que el cliente lo acepte; es
decir, definiciones medibles de los atributos necesarios
para que el conjunto de productos sea aceptable para
las principales partes interesadas.
criterios de calidad
producto debe cumplir y las medidas de calidad que
aplicarán quienes inspeccionen el producto terminado.
cronograma
Representación gráfica de un plan (por ejemplo una
carta o diagrama de Gantt), que generalmente describe
una secuencia de tareas, junto con la asignación de
recursos, que colectivamente representan la entrega
del plan. En PRINCE2 las actividades del proyecto
sólo deberían ser documentadas en los cronogramas
asociados con un Plan de Proyecto, Plan de la Fase
o Plan de Equipo. Las acciones que la gestión diaria
asigna se podrán documentar en el archivo del
proyecto pertinente (es decir, en el Registro de Riesgos,
en el Archivo Diario, en el Registro de Cuestiones,
en el Registro de Calidad) si no requieren actividad
considerable.
342 | Glosario

cuestión Documentación de Inicio del Proyecto

Un evento importante que ha ocurrido, no estaba Un conjunto de documentos lógicos que reúne la
planificado y requiere ser gestionado. Puede ser información clave que se necesita para iniciar el
cualquier asunto, pregunta, solicitud de cambio, proyecto con una base sólida y para transmitir esa
sugerencia o fuera de especificación planteados durante información a todos los involucrados en el proyecto.
el proyecto. Las cuestiones de proyecto pueden ser
sobre cualquier tema relacionado con el proyecto. Ejecutivo
La única persona responsable de asegurarse de que un
dependencias (plan) proyecto cumpla sus objetivos y entregue los beneficios
La relación entre productos o actividades. Por ejemplo, previstos. Esta persona debería asegurarse de que el
el desarrollo del Producto C no se puede iniciar hasta proyecto conserve su enfoque comercial, de que cuente
que los Productos A y B hayan sido desarrollados. Las con una autoridad clara y de que tanto el trabajo como
dependencias pueden ser internas o externas. Las los riesgos sean gestionados activamente. El Ejecutivo
dependencias internas son aquellas que están bajo el es el presidente de la Junta de Proyecto. Representa al
control del Project Manager. Las dependencias externas cliente y es responsable del Business Case.
son aquellas que están fuera del control del Project
Manager. Por ejemplo, la entrega por parte de otro ejecutor de riesgo
proyecto de un producto requerido por este proyecto. El propietario de una acción, que se nombra para
abordar el riesgo. Algunas acciones podrían no estar
Descripción de Producto dentro de la competencia del propietario del riesgo para
Una descripción del propósito de un producto, su ser controladas explícitamente. En ese caso debería
composición, origen y criterios de calidad. Se crea nombrarse a un propietario de la acción para abordar el
durante la planificación, tan pronto como sea posible riesgo. Esta persona necesitará mantener al propietario
después de que la necesidad para el producto haya sido del riesgo informado al respecto.
identificada.
elemento de configuración
Descripción del Producto del Proyecto Una entidad que está sujeta a la gestión de la
Un tipo especial de Descripción de Producto que se configuración. La entidad podría ser un componente de
utiliza para obtener el consentimiento del usuario un producto, un producto o un conjunto de productos
acerca del alcance y los requerimientos del proyecto, en una release.
para definir las expectativas de calidad del cliente y los
criterios de aceptación para el proyecto. enfoque del proyecto
Una descripción de la manera en que el trabajo del
descripción del rol proyecto se debe enfocar. Por ejemplo: ¿se desarrollará
Describe el conjunto de responsabilidades específicas un producto desde cero o se comprará un producto que
para un rol. ya existe?

desencadenante entrega
Un evento o una decisión que activa un proceso de La transferencia de la propiedad de un conjunto de
PRINCE2. productos al o a los respectivos usuarios. El conjunto de
productos se conoce como release. Podría haber más de
diagrama de flujo de los productos una entrega durante la vida de un proyecto (entrega por
Un diagrama que muestra la secuencia de producción fases). La entrega final tiene lugar durante el proceso
de los productos contenidos en la estructura jerárquica del Cierre de un Proyecto.
de productos, así como las interdependencias entre
ellos. equipo de gestión del proyecto
La estructura de gestión del proyecto en su totalidad,
que incluye la Junta de Proyecto, el Project Manager,
cualquier rol de Team Manager y aquellos encargados
de la Garantía y del Apoyo al Proyecto.
 Glosario | 343

estimación del riesgo estructura del equipo de gestión del

La estimación de la probabilidad y del impacto de proyecto
un riesgo individual, teniendo en cuenta las normas Un organigrama que muestra el personal asignado a los
predeterminadas, los niveles de riesgo fijados como roles del equipo de gestión del proyecto y su relación de
meta, las interdependencias y otros factores pertinentes. delegación y de dependencia.

estrategia estructura jerárquica de productos

Un enfoque o línea a adoptar, diseñado para lograr una
finalidad a largo plazo. Las estrategias pueden existir a
diferentes niveles – a nivel corporativo, de programa y
proyecto. A nivel de proyecto, PRINCE2 define cuatro
estrategias: Estrategia de Gestión de la Comunicación,
Estrategia de Gestión de la Configuración, Estrategia de
Gestión de la Calidad y Estrategia de Gestión del Riesgo.
estrategia alternativa
(respuesta al riesgo) documentarse en un testimonio formal.
Una respuesta al riesgo frente a una amenaza en la
cual se pone en práctica un plan de emergencia con las
medidas que se tomarán para reducir el impacto de la
amenaza si ocurriese el riesgo.
Una jerarquía de todos los productos que han de
producirse durante un plan.
Evaluación al Final de Fase
La revisión del Informe al Final de Fase realizada por la
Junta de Proyecto y el Project Manager para decidir si se
aprueba el Plan de la Fase siguiente. Dependiendo del
tamaño y la importancia del proyecto, la revisión puede
ser formal o informal. La autoridad para proceder debe
evaluación de excepción
Una revisión por la Junta de Proyecto para aprobar (o
rechazar) un Plan de Excepción.

Estrategia de Gestión de la Calidad evaluación del riesgo

Una estrategia que define las técnicas y las normas de El proceso de comprender el efecto neto de las
calidad a aplicar y las diversas responsabilidades para amenazas y las oportunidades identificadas en una
lograr, durante un proyecto, los niveles de calidad actividad cuando éstas se suman.
requeridos.
evitar (respuesta al riesgo)
Estrategia de Gestión de la
Una respuesta al riesgo frente a una amenaza que
Comunicación permite que ésta no tenga impacto o no ocurra.
Una descripción de los medios y de la frecuencia de la
comunicación entre el proyecto y las partes interesadas excepción
en el proyecto. Una situación en la que se puede pronosticar que habrá
una desviación que superará los niveles de tolerancia
Estrategia de Gestión de la acordados entre el Project Manager y la Junta de
Configuración Proyecto (o entre la Junta de Proyecto y la gerencia
Una descripción de cómo se controlarán y protegerán corporativa o del programa).
los productos del proyecto y quién lo hará.
expectativas de calidad del cliente
Estrategia de Gestión del Riesgo Una declaración sobre la calidad esperada del producto
Una estrategia que describe aquello que se desea lograr del proyecto, captada en la Descripción del Producto del
al aplicar la gestión del riesgo, junto al procedimiento Proyecto.
que se adoptará, los roles y responsabilidades, las
tolerancias de riesgo, la secuencia temporal de las
intervenciones de la gestión del riesgo, las herramientas
y las técnicas que se utilizarán y los requerimientos de
presentación de informes.
344 | Glosario

Expediente del Proyecto fuera de especificación

Descripción del propósito, coste, tiempo y de Algo que el proyecto debería facilitar pero que
los requerimientos de desarrollo así como de las actualmente no lo hace (o se prevé que no lo hará). Esto
restricciones para un proyecto. Se crea con anterioridad podría ser un producto que falta o un producto que no
al proyecto, durante el proceso de la Puesta en Marcha cumple sus especificaciones. Es un tipo de cuestión.
de un Proyecto y se utiliza durante el proceso del Inicio
de un Proyecto para crear la Documentación del Inicio garantía
del Proyecto y sus componentes. Es reemplazado por la Todas las acciones sistemáticas necesarias para
Documentación de Inicio del Proyecto y no se mantiene. proporcionar confianza de que la meta (sistema,
proceso, organización, programa, proyecto, resultado
fase final, beneficio, competencia, resultado del producto,
Véase ‘fase de gestión’ o ‘fase técnica’. producto a entregar) es apropiada. La definición
de “apropiado” podría ser subjetiva u objetiva en
fase de gestión diferentes circunstancias. La inferencia es que la
Una sección del proyecto que el Project Manager está garantía tendrá un nivel de independencia con respecto
gestionando en nombre de la Junta de Proyecto en de aquello que se está garantizando. Véase también
cualquier momento dado, al final de la cual la Junta ‘Garantía del Proyecto’ y ‘garantía de calidad’.
de Proyecto querrá revisar el progreso hasta la fecha,
el estado del Plan de Proyecto, el Business Case y los garantía de calidad
riesgos y el próximo Plan de la Fase a fin de decidir si se Un control independiente de que los productos
continúa con el proyecto. serán aptos para su propósito o que cumplirán los
requerimientos.
fase de inicio
El período desde el momento en que la Junta de Garantía del Proyecto
Proyecto autoriza el inicio del proyecto hasta el Las responsabilidades de la Junta de Proyecto de
momento en que autoriza el proyecto (o decide no asegurarse de que el proyecto se esté llevando a cabo
seguir adelante con el proyecto). La planificación correctamente. Cada uno de los miembros de la Junta
detallada de la infraestructura para la gestión del de Proyecto tiene un área de enfoque específica para la
proyecto y su establecimiento quedan cubiertos por el Garantía del Proyecto, a saber, garantía comercial para
proceso del Inicio de un Proyecto. el Ejecutivo, garantía del usuario para el o los Usuarios
Principales y garantía del proveedor para el o los
fase técnica Proveedores Principales.
Un método de agrupación de trabajo en base al
conjunto de técnicas utilizadas o los productos creados. gestión de la calidad
Esto da por resultado fases que cubren elementos Las actividades coordinadas para dirigir y controlar una
tales como diseño, construcción e implementación. organización en materia de calidad.
Estas fases son fases técnicas y son un concepto
independiente de las fases de gestión. gestión de la configuración
Actividades técnicas y administrativas relacionadas con
Ficha de un Elemento de la creación, el mantenimiento y el cambio controlado de
Configuración la configuración durante toda la vida de un producto.
Una ficha que describe el estado, la versión y la variante
de un elemento de configuración y cualquier detalle de gestión del riesgo
las importantes relaciones entre ellos. La aplicación sistemática de principios, enfoques y
procesos a las tareas de identificar y evaluar los riesgos
fichas y luego de planificar e implementar las respuestas al
En el contexto de la gestión de la configuración, riesgo.
aquellos productos de gestión dinámicos que guardan
información sobre el progreso del proyecto. Véase
también testimonios documentales.
 Glosario | 345

gestión del proyecto Informe al Final de Fase

La planificación, delegación, seguimiento y control de Un informe que el Project Manager entrega a la
todos los aspectos del proyecto, así como la motivación Junta de Proyecto al final de cada fase de gestión del
de los involucrados, para alcanzar los objetivos del proyecto. Este informe proporciona información sobre el
proyecto dentro de las metas de desarrollo previstas en desarrollo del proyecto durante la fase y sobre su estado
términos de tiempo, coste, calidad, alcance, beneficios al final de dicha fase.
y riesgos.
Informe al Final de Proyecto
gobierno (corporativo) Un informe que el Project Manager facilita a la Junta
La actividad continua de mantener un sólido sistema de Proyecto, que confirma la entrega de todos los
de control interno mediante el cual los directores y productos y presenta un Business Case actualizado
dirigentes de una organización aseguran que se hayan y una evaluación de lo bien que el proyecto se ha
puesto en práctica sistemas efectivos de gestión, con desarrollado en función de la Documentación de Inicio
inclusión de sistemas de control y seguimiento de del Proyecto original.
finanzas a fin de proteger el activo, la productividad
financiera y la reputación de la organización. Informe de Cuestiones
Un informe que contiene la descripción, la evaluación
gobierno (proyecto) del impacto y las recomendaciones para una solicitud
Aquellas áreas del gobierno corporativo que se de cambio, un fuera de especificación o un problema/
relacionan específicamente con las actividades del asunto. Sólo se crea para aquellas cuestiones que
proyecto. El gobierno eficaz de la gestión del proyecto necesitan ser manejadas formalmente.
asegura que la cartera de proyectos de una organización
esté alineada con los objetivos de la organización, que Informe de Desarrollo
se entregue con eficiencia y que sea sostenible. Informe basado en tiempo del Project Manager para
la Junta de Proyecto sobre el progreso de una fase del
hito proyecto.
Un evento de importancia en el cronograma del plan
como, por ejemplo, la terminación de Paquetes de Informe de Excepción
Trabajo clave, una fase técnica o una fase de gestión. Una descripción de una situación de excepción, su
impacto, las opciones disponibles, una recomendación
horizonte de planificación y el impacto de la recomendación. El Project Manager
El período de tiempo en el cual es posible planificar con prepara este informe para la Junta de Proyecto.
precisión.
Informe del Punto de Control
impacto (de riesgo) Un informe del progreso basado en la información
El resultado de que se concrete una amenaza o una recopilada en un punto de control, entregado por
oportunidad determinada o la anticipación de dicho un equipo al Project Manager y que proporciona
resultado. información según lo definido en el Paquete de Trabajo.

incrementar (respuesta al riesgo) Informe sobre el Estado de los

Una respuesta al riesgo frente a una oportunidad en
la cual se toman medidas proactivas para incrementar
tanto la probabilidad de que el evento ocurra como el
impacto del evento si ocurriese.
Productos
Un informe sobre el estado de los productos. Los
productos requeridos se pueden especificar por su
identificador o por la parte del proyecto en la que se
desarrollaron.
346 | Glosario

Informe sobre las Lecciones métodos en cascada

Un informe que documenta cualquier lección que
se puede aplicar de forma útil a otros proyectos. El
propósito del informe es provocar la acción de modo
que las lecciones positivas resultantes de un proyecto
puedan ser implementadas en la manera de trabajar de
la organización y que la organización pueda evitar las
lecciones negativas en proyectos futuros.
Un enfoque de desarrollo que es lineal y secuencial
con metas definidas para cada fase de desarrollo. Una
vez que una fase de desarrollo ha sido completada, el
desarrollo pasa a la próxima fase y no se regresa a las
fases anteriores (de allí la analogía con el agua que fluye
por la ladera de una montaña y que no puede volver
atrás).

informes normas corporativas o del programa

Productos de gestión que proporcionan una imagen Éstas son normas globales que el proyecto debe
instantánea del estado de ciertos aspectos del proyecto. observar. Influirán en las cuatro estrategias del proyecto
(Estrategia de Gestión de la Comunicación, Estrategia
inspección de calidad de Gestión de la Configuración, Estrategia de Gestión
Una evaluación sistemática y estructurada de un de la Calidad y Estrategia de Gestión del Riesgo) y en los
producto, que dos o más personas cuidadosamente controles del proyecto.
seleccionadas (el equipo de revisión) llevan a cabo de
una manera planificada, documentada y organizada. notificación de autorización del proyecto
Asesoramiento por parte de la Junta de Proyecto para
línea de tolerancia del riesgo informar a todas las partes interesadas y a las sedes
Una línea que se traza en el perfil de riesgo resumido. donde se desarrollará que el proyecto ha sido autorizado
Los riesgos que aparecen por encima de esta línea no se y para solicitar cualquier apoyo logístico necesario (por
pueden aceptar (tolerar) sin que sean remitidos a una ej. medios de comunicación, equipos y cualquier apoyo
autoridad superior. Para un proyecto, el Project Manager al proyecto) suficiente para la duración del proyecto.
remitiría estos riesgos a la Junta de Proyecto.
notificación de cierre
lista de productos Aviso de la Junta de Proyecto para informar a todas
Una lista de los productos principales de un plan y sus las partes interesadas y a las sedes que los recursos
fechas clave de entrega. del proyecto se pueden disolver y que los servicios de
apoyo, tales como espacio, equipos y acceso, se pueden
mandato de proyecto desinstalar. Debería indicar una fecha de cierre para
cargar costes al proyecto.
Un producto externo generado por la autoridad que
encarga el proyecto que activa la Puesta en Marcha de
notificación de inicio del proyecto
un Proyecto.
Asesoramiento de la Junta de Proyecto para informar
metas de rendimiento a todas las partes interesadas y a las sedes de que el
proyecto se va a iniciar y para solicitar cualquier apoyo
El objetivo de un plan en cuanto a tiempo, coste,
logístico necesario (por ej. medios de comunicación,
calidad, alcance, beneficios y riesgo.
equipos y cualquier apoyo al proyecto) suficiente para la
fase de inicio.
métodos Agile
Los métodos Agile (ágiles) son principalmente métodos oficina de proyecto
de desarrollo de software que aplican el enfoque de
Una oficina temporal establecida para apoyar la entrega
utilizar iteraciones con cortos límites de tiempo de modo
de una iniciativa de cambio específica a ser entregada
tal que los productos se desarrollan progresivamente.
como un proyecto. Si se utiliza, la oficina de proyecto
PRINCE2 es compatible con los principios ágiles.
asume la responsabilidad del rol de Apoyo al Proyecto.
 Glosario | 347

Paquete de Trabajo Plan de Proyecto

El conjunto de información pertinente para la creación
de uno o más productos. Contendrá una descripción
del trabajo, la o las Descripciones de Productos, detalles
de cualquier restricción en la producción y confirmación
del acuerdo entre el Project Manager y la persona o el
Team Manager encargado de implementar el Paquete
de Trabajo que el trabajo se puede realizar dentro de las
restricciones.
parte interesada
Cualquier persona, grupo u organización que puede
afectar, ser afectado o sentirse afectado por una
iniciativa (programa, proyecto, actividad, riesgo).
patrocinador esta información se podrá crear y mantener a nivel del
La principal fuerza motivadora de un programa o
proyecto. PRINCE2 no define un rol para el patrocinador,
pero es sumamente probable que el patrocinador sea
el Ejecutivo en la Junta de Proyecto o la persona que ha
nombrado al Ejecutivo.
perfil de riesgo
Una descripción de los tipos de riesgo a los cuales una
organización se enfrenta y su exposición a esos riesgos.
plan requeridos. Esta técnica tiene en cuenta los productos
Una propuesta detallada para hacer o lograr algo que
pormenoriza qué, cuándo, cómo y quién. En PRINCE2
hay solamente los siguientes tipos de planes: Plan de
Proyecto, Plan de la Fase, Plan del Equipo, Plan de
Excepción y Plan de Revisión de Beneficios.
Plan de Excepción que el plan tenga éxito.
Un plan que a menudo es la consecuencia de un
Informe de Excepción. Para una excepción a nivel de
Plan de la Fase, comprende desde el momento actual
hasta el final de la fase en curso. Si la excepción es a
nivel de proyecto, reemplazaría el Plan de Proyecto.
Un plan de alto nivel que muestra los productos
principales del proyecto, cuándo serán entregados y
a qué coste. Un Plan de Proyecto inicial se presenta
como parte de la Documentación de Inicio del Proyecto.
Se revisará a medida que la información acerca del
progreso real del proyecto esté disponible. Es un
documento de control principal que permite a la Junta
de Proyecto medir el progreso real del proyecto en
relación a las expectativas.
Plan de Revisión de Beneficios
Un plan que define la manera y el momento en que
se puede medir el logro de los beneficios del proyecto.
Si el proyecto se gestiona dentro de un programa,
programa.
Plan del Equipo
Un nivel de plan opcional utilizado como la base para el
control de la gestión de equipos al ejecutar Paquetes de
Trabajo.
planificación basada en el producto
Técnica que conduce al diseño de un plan exhaustivo
basado en la creación y la entrega de los resultados
previos necesarios, los requerimientos de calidad y las
dependencias entre productos.
prerrequisitos (plan)
Cualquier aspecto fundamental que debe existir
previamente y que debe mantenerse en vigencia para
presupuesto para cambios
Fondos asignados a la Autoridad de Cambios
disponibles para ser gastados en solicitudes de cambios
autorizadas.

Plan de la Fase PRINCE2

Un plan detallado utilizado como la base para el control Un método que apoya ciertos aspectos seleccionados
de la gestión del proyecto durante toda una fase. de la gestión de proyectos. El acrónimo PRINCE significa
PRojects in a Controlled Environment (Proyectos en un
Entorno Controlado).

principio de PRINCE2
Las obligaciones que orientan en las buenas prácticas
para la gestión del proyecto, que son la base de la
gestión de un proyecto PRINCE2.
348 | Glosario

probabilidad producto especializado

Ésta es la posibilidad evaluada de que una amenaza o Un producto cuyo desarrollo es el objeto del plan.
una oportunidad determinada se concrete, incluyendo Los productos especializados son específicos para
una estimación de la frecuencia con la cual ésta se un proyecto individual (por ejemplo una campaña
podría presentar. publicitaria, un sistema de tickets para parking,
cimientos para un edificio, un nuevo proceso comercial,
problema/asunto etc.). También conocido como un producto a entregar o
Un tipo de cuestión (que no sea una solicitud de cambio resultado.
o un fuera de especificación (variación de especificación)
que el Project Manager necesita resolver o para la cual productor
debe presentar una excepción. La persona o el grupo responsable de desarrollar un
producto.
procedimiento
Una serie de acciones para un aspecto determinado de programa
la gestión del proyecto establecida específicamente para Una estructura organizativa flexible y temporal creada
el proyecto, por ejemplo, un procedimiento de gestión para coordinar, dirigir y controlar la implementación de
del riesgo. un conjunto de actividades y proyectos relacionados
a fin de entregar los resultados finales y los beneficios
proceso relacionados con los objetivos estratégicos de la
Un conjunto estructurado de actividades diseñadas para organización. Es probable que un programa tenga una
lograr un objetivo específico. Un proceso toma una o vida que abarque varios años.
más aportaciones definidas y las convierte en resultados
definidos. Project Manager
La persona a quien se le ha otorgado la autoridad y
producto responsabilidad de la gestión diaria del proyecto a fin
Una aportación o resultado, ya sea tangible o intangible, de que entregue los productos requeridos dentro de las
que se puede describir por adelantado, creados y restricciones acordadas con la Junta de Proyecto.
testeados. PRINCE2 cuenta con dos tipos de productos –
productos de gestión y productos especializados. propensión al riesgo
La actitud única de una organización hacia los riesgos,
producto a entregar que a su vez determina la cantidad de riesgo que
Véase ‘resultado’. considera aceptable.

producto de gestión propietario del riesgo

Un producto que se requerirá como parte de la gestión
del proyecto y para establecer y mantener la calidad
(por ejemplo, Informes de Desarrollo, Informe al Final
de Fase, etc.). Los productos de gestión son constantes,
cualquiera sea el tipo de proyecto, y se pueden
utilizar como se describe o con cualquier modificación
pertinente, para todos los proyectos. Hay tres tipos
de productos de gestión: versión baseline, fichas e
informes.
Una persona nombrada que es responsable de la
gestión, del seguimiento y del control de todos los
aspectos de un riesgo determinado que le ha sido
asignado, incluyendo la implementación de respuestas
seleccionadas para hacer frente a las amenazas o para
maximizar las oportunidades.

producto del proyecto

Aquello que el proyecto debe entregar a fin de obtener
aceptación.
 Glosario | 349

Propietario Responsable Principal punto de control

(SRO - Senior Responsible Owner) Una revisión del progreso a nivel de equipo y basada en
Un término del gobierno del Reino Unido para el tiempo.
la persona responsable de asegurarse de que un
proyecto o programa de cambio cumpla con sus rechazar (respuesta al riesgo)
objetivos y entregue los beneficios previstos. Debería Una respuesta a un riesgo (oportunidad) en la cual se
ser el propietario del cambio comercial global que el toma una decisión consciente e intencionada de no
proyecto apoya. El Propietario Responsable Principal aprovechar o incrementar la oportunidad, al haber
(SRO) debería asegurase de que el cambio conserve su discernido que es más económico hacer esto que
enfoque comercial, de que cuente con una autoridad intentar una acción de respuesta al riesgo. Se debería
clara y de que el contexto, incluyendo los riesgos, sea continuar realizando el seguimiento la oportunidad.
gestionado activamente. El SRO debe tener suficiente
autoridad dentro de la organización, ya que debe asumir recomendación de cierre
personalmente la responsabilidad de que el proyecto Una recomendación que el Project Manager prepara
se entregue con éxito. Debería ser reconocido como el para que la Junta de Proyecto la envíe como notificación
propietario del proyecto en toda la organización. de cierre del proyecto cuando la junta concuerde en que
El SRO nombra al Ejecutivo del proyecto (o en algunos el proyecto se puede cerrar.
casos podría elegir ser el Ejecutivo).
rectificación
proveedor Un conjunto de acciones para resolver una amenaza a
La persona, el grupo o grupos responsables de las tolerancias de un plan o un defecto en un producto.
proporcionar los productos especializados del proyecto.
reducir (respuesta al riesgo)
Proveedor Principal Una respuesta a un riesgo en la cual se realizan acciones
Es el rol de la Junta de Proyecto que proporciona proactivas para reducir la probabilidad de que el evento
conocimientos y experiencia sobre la o las principales ocurra al ejercer cierta forma de control, y/o reducir el
disciplinas relacionadas con la elaboración del o de los impacto del evento si se concretase.
productos a entregar del proyecto. El Proveedor Principal
representa los intereses del proveedor dentro del Registro de Calidad
proyecto y proporciona recursos del proveedor. Un registro que contiene detalles resumidos de todas
las actividades de control de calidad planificadas y
proximidad (del riesgo) completadas. El Project Manager y la Garantía del
La dimensión temporal del riesgo - la probabilidad de Proyecto utilizan el Registro de Calidad como parte de la
que el riesgo se concrete y la severidad de su impacto revisión del progreso.
variarán dependiendo de cuándo ocurra el riesgo.
Registro de Cuestiones
proyecto Un registro que se utiliza para recoger y guardar
Una organización temporal que se crea con el propósito información sobre todas las cuestiones que se están
de entregar uno o más productos comerciales de gestionando formalmente. El Project Manager debería
acuerdo con un Business Case convenido. hacer el seguimiento del Registro de Cuestiones con
regularidad.
proyecto PRINCE2
Un proyecto que aplica los principios de PRINCE2. Registro de Riesgos
Un testimonio de los riesgos identificados, relacionados
puesta en marcha con una iniciativa, incluyendo su estado y su historial.
Las actividades anteriores al proyecto realizadas por el
Ejecutivo y el Project Manager para producir el Business
Case preliminar, el Expediente del Proyecto y el Plan de
la Fase de Inicio.
350 | Glosario

registros riesgo inherente

Depósitos formales gestionados por el Project
Manager cuyo formato, composición y uso requieren
la aprobación de la Junta de Proyecto. PRINCE2 cuenta
con tres registros: Registro de Cuestiones, Registro de
Riesgos y Registro de Calidad.
release
El conjunto de productos en una entrega. El contenido
de una release se gestiona, se prueba y se utiliza como
una única entidad. Véase también ‘entrega’.
Exposición a daño surgida de un riesgo específico antes
de que se tome cualquier medida para su gestión.
riesgo residual
El riesgo que perdura después de haberse aplicado la
respuesta al riesgo.
sede
El lugar físico donde se desarrolla el trabajo del proyecto
(por ejemplo una oficina o un recinto de construcción).

respuesta al riesgo sistema de gestión de la calidad

Acciones que se pueden realizar para llevar una El conjunto completo de normas, procedimientos
situación a un nivel en el cual la exposición al riesgo y responsabilidades de calidad para una sede u
es aceptable para la organización. Estas respuestas organización. En el contexto de proyecto, ‘sedes’ y
se encuentran dentro de una serie de categorías de ‘organizaciones’ se deberían interpretar como la o
respuesta al riesgo. las organizaciones permanentes o semipermanentes
que patrocinan el trabajo del proyecto, es decir, son
restricciones ‘externas’ a la organización temporal del proyecto.
Las constricciones o limitaciones a las cuales está sujeto Un programa, por ejemplo, puede considerarse una
el proyecto. organización semipermanente que patrocina proyectos
– y podrá tener un sistema de gestión de la calidad
resultado documentado.
Un producto especializado que se entrega a un usuario
o a usuarios. Nótese que los productos de gestión no sistema de gestión de la
son resultados sino que se crean únicamente con el configuración
propósito de gestionar el proyecto. El conjunto de procesos, herramientas y bases de
datos que se utilizan para gestionar los datos de
resultado final configuración. Generalmente, un proyecto utilizará el
El resultado del cambio que normalmente afecta el sistema de gestión de la configuración del cliente o de
comportamiento en el mundo real y/o las circunstancias. la organización proveedora.
Los resultados finales son deseados cuando se concibe
un cambio. Se logran como resultado de actividades solicitud de cambio
realizadas para efectuar el cambio. Una propuesta de cambio a una versión baseline. Es un
tipo de cuestión.
revisión de calidad
Véase ‘inspección de calidad’. suposición
Una declaración considerada verdadera durante la
revisor planificación, pero que podría cambiar más adelante. Se
Una persona o grupo independiente del productor que hace una suposición cuando algunos hechos todavía no
evalúa si un producto cumple con sus requerimientos se conocen o no se han decidido. Su uso, en general, se
según lo definido en su Descripción de Producto. reserva para asuntos de tal magnitud que si cambian o
resultan no ser verdaderos se requerirá replanificación
riesgo considerable.
Un evento o un conjunto de eventos inciertos que,
si ocurriesen, tendrán un efecto en el logro de los
objetivos. Un riesgo se mide por una combinación de la
probabilidad de que ocurra una oportunidad o amenaza
percibida y la magnitud de su impacto en los objetivos.
 Glosario | 351

Team Manager tolerancia de alcance

La persona responsable de la producción de aquellos
productos asignados por el Project Manager de
conformidad con lo definido en el Paquete de Trabajo
con niveles de calidad apropiados, calendarios y a un
coste aceptable para la Junta de Proyecto. El rol de Team
Manager rinde cuentas y recibe órdenes del Project
Manager. Si no se ha nombrado un Team Manager, el
Project Manager asume las responsabilidades del rol de
Team Manager.
técnica de revisión de calidad de gestión inmediatamente superior. La tolerancia de
Una técnica de inspección de la calidad con roles
definidos y una estructura específica. Se diseña para
evaluar si un producto que toma la forma de un
documento (o similar, por ejemplo, una presentación)
está completo, cumple con las normas y satisface
los criterios de calidad acordados en su Descripción
de Producto pertinente. Los participantes se toman
de entre aquellos que cuentan con la competencia
necesaria para evaluar su idoneidad para el propósito
deseado.
La desviación en el alcance de un plan que se permite
antes de que se deba presentar una excepción sobre la
desviación al siguiente nivel de gestión. La tolerancia
de alcance se documenta en el plan respectivo bajo la
forma de una nota o referencia a la estructura jerárquica
de productos para ese plan. Véase ‘tolerancia’.
tolerancia de beneficios
La desviación en los beneficios esperados que se permite
antes de que se deba presentar una excepción al nivel
beneficios se documenta en el Business Case. Véase
también ‘tolerancia’.
tolerancia de calidad
La tolerancia establecida para un criterio de calidad de
un producto que define la gama de valores aceptables.
La tolerancia de calidad se documenta en la Descripción
del Producto del Proyecto (para la tolerancia de calidad
a nivel de proyecto) y en la Descripción de Producto
para cada producto a ser entregado.

temática tolerancia de coste

Un aspecto de gestión del proyecto que se necesita
abordar continuamente y que requiere tratamiento
específico para que los procesos de PRINCE2 sean
efectivos.
testimonios documentales
Productos de gestión dinámicos que guardan
información sobre el progreso del proyecto. Véase
también ‘fichas’.
testimonios documentales de calidad Proyecto sobre dicha situación. Las tolerancias de riesgo
Constancias que se guardan para demostrar que se han
realizado las actividades de garantía de calidad y control
de calidad requeridas.
tolerancia ejemplo una amenaza a un servicio operacional). La
La desviación permisible por encima y/o debajo de
la meta de un plan en cuanto a tiempo y coste, sin
la necesidad de presentar una excepción al nivel de
gestión inmediatamente superior. También podría haber
niveles de tolerancia para calidad, alcance, beneficios y
riesgo. La tolerancia se aplica a nivel de proyecto, fase y
equipo.
La desviación en el coste del plan que se permite antes
de que se deba presentar una excepción al nivel de
gestión inmediatamente superior. La tolerancia de coste
se documenta en el plan respectivo. Véase también
‘tolerancia’.
tolerancia de riesgo
Los umbrales de exposición al riesgo que, cuando
se exceden, activarán la presentación de un Informe
de Excepción para llamar la atención de la Junta de
podrían incluir límites a los riesgos totales del plan
(por ejemplo la suma de los costes adicionales de las
amenazas deberá ser inferior al 10% del presupuesto
del plan) o límites a cualquier amenaza individual (por
tolerancia de riesgo se documenta en la Estrategia de
Gestión del Riesgo.
tolerancia de tiempo
La desviación de tiempo permitida en un plan antes
de que se deba presentar una excepción al nivel
inmediatamente superior. La tolerancia de tiempo
se documenta en el plan respectivo. Véase también
‘tolerancia’.
352 | Glosario

tramo (tranche)
Un término de la gestión de programas que describe
un grupo de proyectos estructurados según cambios
específicos esperados en la entrega de beneficios y
competencias.

transferir (respuesta al riesgo)

Una respuesta a una amenaza frente a la cual un tercero
asume la responsabilidad de una parte del impacto
financiero de la amenaza. (por ejemplo, a través de
un seguro o por medio de cláusulas apropiadas en un
contrato).

Usuario Principal
El rol, en la Junta de Proyecto, responsable de
asegurarse de que las necesidades del usuario se
especifiquen correctamente y de que la solución
satisfaga dichas necesidades.

usuario(s)
La persona o el grupo que usará uno o más de los
productos del proyecto.

variante
Una variación sobre un producto en versión baseline.
Por ejemplo, un manual de funcionamiento podría tener
una variante en inglés y una variante en español.

versión
Una versión baseline específica de un producto. Las
versiones generalmente utilizan convenciones para
nombres que permiten identificar la secuencia o fecha
del baseline a identificar. Por ejemplo, la versión 2 del
Plan de Proyecto es la versión baseline después de la
versión 1 del Plan de Proyecto.

versión baseline
(producto de gestión)
Un tipo de producto de gestión que define aspectos del
proyecto y que una vez aprobado está sujeto a control
de cambios.
Índice
Índice
Nota: Los números de página en negritas indican
referencias a tablas. Aquéllos en cursivas a figuras.
A paquetes de trabajo 194
aceptación 53, 156, 161, 186, 219 por el project manager 118
actividades 77, 132 responsabilidades para 157
diagrama de 79
en cierre de un proyecto 228–236
en control de una fase 186–202 B
en dirección de un proyecto 152–162 baseline 19, 26, 55, 60, 62, 69, 70, 72, 83, 155, 161,
en gestión de la entrega de productos 206 198
en inicio de un proyecto 166–182 cambios a 103
en la gestión de los límites de fase 214–224 descripción de producto 75
en los paquetes de trabajo 206–210 para control 121
en puesta en marcha de un proyecto 138–148 para controlar el progreso 121
orientadas al project manager 186 beneficios 4, 5, 24, 24–25, 178
orientadas al team manager 186–202 confirmación de 26
post-proyecto 231 esperados 23, 28
actividades y dependencias revisión de 26, 153, 231
identificar 77 Beneficios esperados
actualizaciones sobre el progreso 118 en Business Case 28
adaptación 237–258 beneficios netos 30
adaptación para corresponder al entorno del Body of Knowledge 256
proyecto 15 buenas prácticas 6, 8, 11, 257.
alcance 5 Véase también mejores prácticas
alcanzable 23 business as usual.
amenaza 92 Véase negocio habitual
análisis de las partes interesadas 47 Business Case 3, 8, 11, 19, 21–32, 53, 115, 144, 186,
ejemplo 47 214, 264
análisis de Pareto 93 adaptación de 242
análisis de sensibilidad 30 contenido 27
Apoyo al Proyecto 44 Definición 23–24
responsabilidades 31, 49, 66, 83, 99, 111, 125 desarrollo 25
aprender de la experiencia 12 en contexto comercial 249
aprobador 60 enfoque en 24
aprovechar 96 mantenimiento 25
árboles de probabilidad 93 no verificado 26
Archivo Diario 106, 122, 130, 167, 146, 169, 170, 248, perfeccionar 178, 179
139 preliminar 25
creación 139 Propósito 23, 264
en adaptación 249 proveedor
Propósito 263 ejemplo de 250
Archivo sobre las Lecciones 123, 261–262 relación entre resultados y beneficios 24
propósito 261 responsabilidades 31
Association for Project Management 256, 296 ruta de desarrollo 25
auditoría 55, 58, 60, 65, 105, 56 tipos 24
aumento del alcance 5 verificación 25
autoridad 8, 39, 151.
Véase también delegación
Autoridad de Cambios 41, 105, 243, 245, 273, 299, C
317
cadena crítica.
ejemplo 41
Véase ruta crítica
autorizar 152, 152–157, 153, 154, 155, 156, 157
Calendario
listas de control 318–321
356 | Índice
en Business Case 29
calendarios 5
calidad 5, 19, 51–66
adaptación de 245
en contexto comercial 251
enfoque PRINCE2 55
propósito 53
responsabilidades 66
cambio 3, 19, 101–112, 118
adaptación de 245
aprobar 299
aprobas 41
autoridad de 41
en contexto comercial 251
enfoque PRINCE2 104
Propósito 103
responsabilidades 111
solicitud de 104, 106, 279, 110
cambio comercial 3.
Véase también cambio
características (del proyecto) 3
causa del riesgo 92
centro de excelencia 46, 156
ejemplo 46
cierre
autorización 228
notificación de 161, 234, 299, 321
planificado 229
prematuro 153, 157, 228, 230, 319
Cierre de un Proyecto 225–236
Contexto 228
cliente/proveedor
contexto 71
entorno 24, 35, 267
entorno comercial 241, 249, 250
relación 36, 43, 207
comercial
interés de 36
commercial off the shelf 144
compartir 96
competencias 7, 35
de Apoyo al Proyecto 306
de la Autoridad de Cambios 305
de la Garantía del Proyecto 305
de la Junta de Proyecto 300
del Project Manager 303
del Team Manager 303
complejidad 247
comunicación 8, 152
riesgos 97
comunicar 97
lecciones 283
resultados 63
concesión 110
condiciones del producto 75
configuración
gestión de la 103
conflictos
evitar 36, 43
Contexto
Cierre de un Proyecto 228
Control de Fase 186
Dirección de un Proyecto 151
Gestión de la Entrega de Productos 205
Gestión de los Límites de Fase 214
Inicio de un Proyecto 166
Puesta en Marcha de un Proyecto 138
Contrabeneficios 27, 29, 264
Contrabeneficios previstos
en Business Case 29
contrato 177, 268
control.
Véase también controles del progreso;
Véase también controles del proyecto
fases de gestión para 118
listas de 6, 317
puntos de 80
control (configuración) 107
control de calidad 54, 61
Control de una Fase 183–202, 185
contexto 186
propósito 185
controles del progreso 115
controles del Project Manager 118
controles del proyecto 173–174
coste 4, 5, 11, 14, 30, 53, 57, 161, 162, 205, 216, 217
de desarrollo 57
operativos 57
Costes
en Business Case 29
COTS 144.
Véase Producto comercial en existencia
creación de equipos
ejemplo 45
credibilidad 39
criterios de aceptación 55, 57, 58, 66, 153, 215
cambios a 215
cumplir 228
ejemplo 58
criterios de calidad
ejemplo 59
Criterios de calidad 59
cronograma 78, 81
Cuadro de hitos 122
Cuerpos de Conocimientos 256.
Véase también body of knowledge
Cuestiones 104
tipos de 104
Curva en forma de S 122
 Índice | 357

D ejecutor del riesgo 97

estructura jerárquica de productos 311
DDPN 57
estructura jerárquica de riesgos 91
Decidir 109
estudio de viabilidad
Delegación de autoridad 117
ciclo de vida 254
dependencias
excepción 36
ejemplo 77
expectativa de calidad 57
Dependencias 77
participación de las partes interesadas 47
Descripción del Producto del
pioridad y gravedad 105
Proyecto 58
planificación basada en el producto 307
Descripción del Producto del Proyecto 74, 267–269
posible condiciones de producto 75
Ejemplo 311
prioridad y gravedad 105
Propósito 267
productos de gestión 249
Descripción de Producto 265–266
propietario del riesgo 97
Ejemplo 312
registro de calidad 60
Propósito 265
responsabilidades de un Project Manager 46
Descripciones de Productos 59, 75
resultado 24
diagrama de flujo de los productos 76
resultado final 24
Diagrama de ruta crítica
tabla de responsabilidades 132
ejemplo 81
Tabla de responsabilidades 132
Diagramas de Gantt
técnica de ordenación por prioridad 57
ejemplo 81
técnica de redes de actividades 79
dirección 37, 115, 129, 268, 299.
técnica de valor monetario esperado 94
Véase también Niveles de gestión
tolerancia de riesgo 89
Dirección
enfoque en los productos 14
nivel de gestión 38
entorno cliente/proveedor comercial 249
dirección ad hoc 152, 158–162, 159, 320
Entrega
Dirección de un Proyecto 149–162
nivel de gestión 38
contexto 151
equipo de gestión
Disponibilidad 39
ejemplo de cambio 44
Documentación de Inicio del Proyecto 268–269
equipo de gestión del proyecto
Propósito 268
cambios en 44
equipos del proyecto
E capacitación 45
estimación 77, 78
Efecto del riesgo 92 estimar 93
Ejecutivo 39 Estrategia alternativa 96
responsabilidades 31, 49, 66, 83, 99, 111, 125 Estrategia de Gestión de la Calidad 58, 270–271
ejecutor del riesgo Propósito 270
ejemplo 97 Estrategia de Gestión de la Comunicación 48, 154,
Ejecutor del riesgo 97 193, 194, 196, 220, 271–272
ejemplo 312 Propósito 271
análisis de las partes interesadas 47 Estrategia de Gestión de la Configuración 168,
autoridad de cambios 41 272–273
beneficios 24 Propósito 272
business case no verificado 26 responsabilidades 170
Business Case proveedor 250 Estrategia de Gestión del Riesgo 273–274
cambio en el equipo de gestión 44 Propósito 273
centro de excelencia 46 estructura jerárquica de productos 74
creación de equipos 45 ejemplo 311
criterios de aceptación 58 estructura jerárquica de riesgos 91
criterios de calidad 59 ejemplo 91
DDPN 57 evaluación de la inversión
dependencias 77 técnicas 30
descripción del producto del proyecto 311 Evaluación de la inversión
Descripción de Producto 312 en Business Case 29
Diagrama de flujo de los productos 313
358 | Índice

evento del riesgo 92 H

evitar 96
habilidad para delegar 39
examinar 108
hitos 80
Excepciones 115, 118, 124
expectativas de calidad 56
ejemplo 57 I
Expediente del Proyecto 275–276
Propósito 275 identificación 107
implementar 109
implementar (riesgos) 97
F Incrementar 97
Informar sobre el progreso 123
fase de entrega final 130
Informe al Final de Fase 124, 277–278
fase de inicio 130
adaptación de 249
fases de entrega posteriores 130
Propósito 277
fases de gestión
Informe al Final de Proyecto 124, 278–279
duración 119
Propósito 278
número 119
Informe de Cuestiones 106, 279–280
para ejercer control 118
adaptación de 249
fases técnicas 119, 120
Propósito 279
Ficha de un Elemento de Configuración 191, 276
Informe de Desarrollo 123, 280–281
crear/preparar 168
Propósito 280
Propósito 276
Informe de Excepción 281
fuera de especificación 110
Propósito 281
Informe del Punto de Control 123, 189, 209, 251,
G 282
adaptación de 249
Gantt Propósito 282
diagrama de 81 Informe sobre el Estado de los Productos 106, 122,
garantía de calidad 54 282–283
Garantía del Proyecto 40 Propósito 282
responsabilidades 31, 49, 66, 83, 99, 111, 125 Informe sobre las Lecciones 123, 283
Gateway Review 255 Propósito 283
gestión Informes sobre el estado 107
niveles de 38, 117 Inicio de un Proyecto 163–182
gestión corporativa contexto 166
autorizar cambios 41 interés
gestión corporativa o del programa 26, 27, 37 comercial 36
responsabilidades 31, 49, 66, 83, 99, 111, 125 proveedor 36
Gestión corporativa o del programa usuario 36
nivel de gestión 37 intereses 36
Gestión de la Configuración 103 introducción a los procesos 127–134
procedimiento 107, 272
Gestión de la Entrega de Productos 203–210
Contexto 205 J
Gestión de los Límites de Fase 211–224
Junta de Proyecto
Contexto 214
tamaño 41
gestión del riesgo 87, 90
justificación comercial 248, 249, 256, 300
gestión del valor ganado 123
continua 11, 23, 94, 152, 217, 249
gestión de proyectos 5
definición 4
Gestión por excepción 14 L
gestión por fases 13
gobierno 35 lecciones de revisión 91
gravedad 105 listas de control 6, 317
ejemplo 105 listas de posibles riesgos 91
lluvia de ideas 74, 91
 Índice | 359

M perfil de riesgo abreviado 95

período de reembolso 30
mejores prácticas 6
PESTLE.
riesgo 89
Véase PASTEL
métodos de calidad 60, 61
Plan 19, 67–84, 286
modelos de riesgo 94
adaptación de 245
MoSCoW.
de Excepción 71, 121
Véase DDPN
de Fase 70, 121
adaptación de 249
N definición 69
del Equipo 71
negocio habitual 3, 160 de proyecto 70
niveles 37 de Realización de los Beneficios 243
niveles de gestión 37, 117 en contexto comercial 251
niveles de organización 37 enfoque PRINCE2 72
nombramiento 38, 137, 152 niveles 70
propósito 69
Propósito 286
O Plan de Proyecto 121
Objetivo Plan de Revisión de Beneficios 155, 243, 249,
de Cierre de un Proyecto 227 288–289, 299
de Control de una Fase 185 Propósito 288
de Dirección de un Proyecto 151 responsabilidades para 302, 304
de Gestión de la Entrega de Productos 205 Planificación (configuración) 107
de Gestión de los Límites de Fase 214 planificación de calidad 54, 55
de Inicio de un Proyecto 165 planificar (riesgos) 94
de Puesta en Marcha de un Proyecto 137 preproyecto 129
OGC presupuestos 81
orientació complementaria 6–7 para cambios 81
orientación complementaria 7 para riesgo 81
Opciones comerciales Presupuestos
en Business Case 28 para riesgos 98
oportunidad 92 PRINCE2
Organización 19, 33–50, 35, 37 beneficios 8
adaptación de 243 estructura 6
en contexto comercial 250 exclusiones 7
estructura de 37, 42 introducción 4
responsabilidades 49 Principios 11–16
Organización corporativa 35 prioridad 105
organización temporal 3 ejemplo 105
problema/asunto 110
Procedimiento de control de cambios y cuestiones
P 107
Procedimiento de gestión de la configuración 107
Paquete de Trabajo 121, 284–285
procesos 129, 131
adaptación de 249
producto
Propósito 284
condiciones del 75
Pareto
productos comerciales 3
análisis de 93
productos de gestión
partes interesadas 46
adaptación de 248
análisis de perfiles 47
en contexto comercial 252
definición de estrategia de participación 47
programa
identificación 47
organización 35
participación 47
Programa 35
participación de las partes interesadas
progreso 19, 113–126
ejemplo 47
actualizaciones sobre 118
PASTEL 91
360 | Índice

adaptación de 245 para actualizar el business case 219

definición 115 para actualizar el plan de proyecto 217
enfoque PRINCE2 116 para autorizar el cierre 162
propósito 115 para autorizar el inicio 153
responsabilidades 125 para autorizar el proyecto 155
revisión del 121 para autorizar un plan 157
project manager para business case 31
responsabilidades para Business Case 30, 144, 179
ejemplo de 46 para calidad 66
Project Manager 43 para cambios 111
qué hace 5 para elaborar un plan de excepción 223
responsabilidades 31, 49, 66, 83, 99, 111, 125 para el Business Case 179
propietario del riesgo 97 para el plan de proyecto 177
ejemplo 97 para enfoque de proyecto 146
proponer 109 para entregar los productos 232
proveedor para estrategia de gestión de la calidad 171
interés de 36 para estrategia de gestión de la comunicación
Proveedor Principal 40 173
responsabilidades 31, 49, 66, 83, 99, 111, 125 para estrategia de gestión de la configuración
proyecto 170
definición de 3 para estrategia de gestión del riesgo 168
en evolución 254 para evaluar el proyecto 234
estudio de viabilidad 254 para fase de inicio 147
Multiorganizativos 252 para informar sobre el desarrollo 196
organización 35 para informar sobre el final de la fase 221
Proyecto 35 para la documentación de inicio proyecto 181
Puesta en Marcha de un Proyecto 135–148 para llevar a cabo rectificaciones 202
contexto 138 para los controles del proyecto 175
para nombramientos 140, 142
para organización 49
R para paquetes de trabajo 207, 188, 191, 208, 209,
razones 190, 210
del Business Case 28 para planes 83
rechazar 97 para planificar la fase siguiente 216
rectificaciones 185, 186, 197, 200, 202 para preparar el cierre planificado 229
llevar a cabo 200 para preparar el cierre prematuro 230
recursos para presentar excepciones 200
asignación 80 para proporcionar dirección ad hoc 159
disponibilidad de 80 para recomendar el cierre del proyecto 235
exigencias de 81 para registrar lecciones 141
nivelar el uso de 80 para registrar y examinar cuestiones y riesgos 198
red de actividades para revisar el estado de la fase 194
ejemplo 79 para riesgos 99
Reducir 96 planes 83
registrar (cuestiones) 107 respuestas a amenazas y oportunidades 95
Registro de Calidad 122, 60, 60 restricciones 38, 40, 82, 138, 145
ejemplo 60 resumen de actividades
Propósito 288 para autorizar 152, 154, 156, 160
Registro de Cuestiones 106, 122, 289–290 para business case 143, 178
Propósito 289 para controles del proyecto 174
Registro de Riesgos 122, 290–291, 89 para cuestiones y riesgos 197
Propósito 290 para documentación de inicio del proyecto 180
relación comercial 36, 152, 166, 188, 249 para elaborar un plan de excepción 222
release 103 para el business case 218
responsabilidades 27, 35–50, 141, 241 para entregar los productos 231
definición de 297–306 para estrategias 167, 169, 170, 172
 Índice | 361

para evaluar el proyecto 233 T

para excepciones 199
tabla de probabilidad-impacto 93, 94
para expediente del proyecto 145
tabla de responsabilidades
para informar sobre el desarrollo 195
ejemplo 132
para informar sobre el final de fase 220
Team Manager 43
para nombramientos 141
responsabilidades 49, 66, 83, 99, 111, 125
para paquetes de trabajo 187, 189, 191, 206, 208,
temáticas 17–20, 19
210
aplicación de las 20
para plan de proyecto 217, 176
formato de las 20
para planificación fase de inicio 146
Testimonios Documentales
para planificas la fase siguiente 215
de aceptación 65
para preparar el cierre planificado 229
de aprobación 65
para preparar el cierre prematuro 230
de calidad 64
para proporcionar dirección ad hoc 158
tolerancias 115, 116
para recomendar el cierre del proyecto 235
de calidad 59
para rectificaciones 201
de riesgo
para registro de lecciones 140
ejemplo 89
para revisar el estado de la fase 192
toma de decisiones 8, 11, 23, 25, 35, 38, 87, 105, 115,
retorno sobre la inversión 30
121, 151, 165, 253, 300
revisión de calidad
Transferir 96
técnica 62
riesgo
causa del 92 U
definición 87
efecto del 92 Usuario
ejecutor del 97 interés de 36
enfoque PRINCE2 88 Usuario Principal 40
evento del 92 responsabilidades 31, 49, 66, 83, 99, 111, 125
propietario del 97
Riesgo 5, 19, 85–100
adaptación de 245 V
analizar 81 valor actual neto 30
en contexto comercial 251 valor esperado 93
en la planificación 82 verificación y auditoría 107
identificar 90 Visión general
propósito 87 de Cierre de un Proyecto 227
responsabilidades 99 de Control de una Fase 185
Riesgos principales de Dirección de un Proyecto 151
en Business Case 30 de Gestión de la Entrega de Productos 205
ROI. de Gestión de los Límites de Fase 213
Véase retorno sobre la inversión de Inicio de un Proyecto 165
roles 36 de Puesta en Marcha de un Proyecto 137
roles y responsabilidades definidos 12
Roles y tareas 36
ruta crítica 79
diagrama de 81

S
scope creep.
Véase aumento del alcance
sesión de lluvia de ideas 91
Solicitud de Cambio 110
A menudo se dice que el cambio es una constante del mundo
moderno. Ya sea que el cambio sea resultado de planificación
estratégica, forme parte de un programa transformacional
o se produzca en respuesta a un imperativo operacional, el
mecanismo para gestionar su entrega es y sigue siendo la
gestión de proyectos.

La versión actual del método PRINCE2TM ha sido diseñada con

miras a hacer más hincapié en los principios que sustentan
el éxito en la gestión de proyectos y para proporcionar
orientación clara sobre la manera de aplicar estos principios
al contexto organizativo dentro del cual operan los
proyectos. Este manual es, por consiguiente, una herramienta

Éxito en la Gestión de Proyectos con PRINCE2TM

fundamental para cualquier persona interesada en lograr
mayor éxito en la gestión de proyectos.

El desafío al cual se enfrentan todas las organizaciones,

grandes o pequeñas y ya sea dentro del sector público o Éxito en la Gestión de Proyectos con PRINCE2TM
privado, es la entrega de cambio a través de una gestión de
proyectos consecuente y sólida. Es aquí donde el método
PRINCE2 de gestión de proyectos realmente añade valor y se
confirma como la norma universalmente reconocida para lograr
éxito en la entrega de proyectos.

ISBN 9780113311651

www.tso.co.uk 9 780113 311651