UNIVERSIDAD NACIONAL

JOS FAUSTINO SNCHEZ CARRIN

FACULTAD DE INGENIERA INDUSTRIAL, SISTEMAS E

INFORMTICA
ESCUELA DE INGENIERA DE SISTEMAS
Formulacin y Evaluacin de Proyectos
MONOGRAFA:
PRINCE2
CICLO:
AUTORES:

VIII
Laos Meja, Aldo
Len Aguilar, Sheyla
Morales Flores, Victor Angel
Polo Sevilla, Andrea Iris
Reyes Reyes, Abel Mximo
Rodrguez Garca, Charly Julio

ASESOR:
Ing. Mandamiento Grados, Romel Ivan
HUACHO PER
2014

CONTENIDO
CAPTULO 1 ...................................................................................................................................................................3
Introduccin a PRINCE2 .........................................................................................................................................3
CAPTULO 2 ...................................................................................................................................................................4
Estudio sobre PRINCE2 ...........................................................................................................................................4
2.1.PRINCE2 en lneas generales .......................................................................................................................4
2.2.Roles de PRINCE2 .............................................................................................................................................5
2.3.Estructura de PRINCE2 ..................................................................................................................................8
2.4.PRINCE2 en cifras .......................................................................................................................................... 38
Impacto de PRINCE2..................................................................................................................................... 38
Aprendiendo PRINCE2................................................................................................................................. 39
Captulo 3..................................................................................................................................................................... 40
PRINCE2 frente a otra metodologa .............................................................................................................. 40
3.1.PRINCE2 frente a PMBOK .......................................................................................................................... 40
Captulo 4..................................................................................................................................................................... 51
PRINCE2 a medida .................................................................................................................................................. 51
4.1.Procesos de PRINCE2 aplicados a un proyecto de pequeo tamao ....................................... 51
4.2.Componentes de PRINCE2 aplicados a un proyecto de pequeo tamao59
4.3.Componentes de PRINCE2 aplicados a un proyecto de gran tamao ...................................... 62
CONCLUSIONES ......................................................................................................................................................... 64
Bibliografa ................................................................................................................................................................. 65

CAPTULO 1
Introduccin a PRINCE2
PRINCE2 es un mtodo estructurado para la gestin de proyectos basado en las
experiencias.
Se basa en la transformacin (negocio eventual o bussines as occasional) frente a
explotacin y mantenimiento (negocio habitual o bussines as usual)
La justificacin del proyecto a travs de la entrega de productos de acuerdo a un
modelo de negocio.
Medio de cambio, organizacin temporal, inter funcional & inter disciplinar, iniciativa
singular, riesgo e incertidumbre
La justificacin del mtodo es lograr los objetivos dentro de las metas de
rendimiento, es decir, que los resultados del proyecto sean compatibles con el
modelo de negocio.
Las actividades del director de proyecto, las variables a controlar, la estructura del
mtodo es el siguiente:

Actividades: Planificar, Delegar, Monitorizar y Controlar

Variables: Coste, Calendario, Calidad, Alcance, Riesgo, Beneficio.

Estructura: 7 principios, 7 temticas, 7 procesos.

Marco metodolgico de PRINCE2.

Integracin con otras pautas de la OGC.

No proporciona.

Aspectos especializados.

Tcnicas detalladas.

Capacidad de direccin.

CAPTULO 2
Estudio sobre PRINCE2
2.1. PRINCE2 en lneas generales
El nombre de PRINCE2 viene de las palabras en ingls Projects In Controlled
Environments, es un mtodo de gestin de proyectos que cubre la gestin, el
control y la organizacin de un proyecto.
PRINCE2 constituye una aproximacin estructurada a la gestin de proyectos,
proporciona un mtodo para gestionar proyectos dentro de un marco de trabajo
claramente definido.
PRINCE2 describe procedimientos para coordinar personas y actividades en un
proyecto, cmo disear y supervisar el proyecto y los pasos a seguir si ocurre
alguna desviacin de lo planificado y es necesario realizar ajustes.
Este mtodo propicia la divisin de las tareas en etapas, lo cual permite una
utilizacin eficiente de los recursos y un seguimiento y monitorizacin muy
ajustada a las tareas reales, que permite que el proyecto se desarrolle de una
forma controlada y organizada.
PRINCE2 es un mtodo ampliamente reconocido, que proporciona un lenguaje
comn a todos los participantes en el proyecto. Incluye descripciones de los
roles de gestin y las responsabilidades asignadas a los participantes en el
proyecto, esto resulta beneficioso a la hora de adaptarlo a un proyecto
determinado con un grado de complejidad y necesidad de habilidades de
organizacin y conocimientos para llevar a cabo las distintas tareas del
proyecto.
PRINCE2 se deriva de un mtodo anterior llamado PROMPTII y del mtodo de
gestin de proyectos PRINCE, cuya versin inicial se desarroll en 1989 como
encargo para el Gobierno del Reino Unido que deseaba contar con un estndar
de gestin de proyectos para las tecnologas de la informacin. Dado que el uso
4

de PRINCE se populariz y empez a aplicarse en otros mbitos externos a las

tecnologas de la informacin, se public PRINCE2 en 1996, como un mtodo
de gestin de proyectos estndar.
La popularidad de este mtodo se ha incrementado con los aos y ahora es un
estndar de facto para la gestin de proyectos en el Reino Unido, su uso se ha
extendido tambin a muchos otros pases del mundo.
En el ao 2009 se public una nueva versin del mtodo, manteniendo el
nombre de PRINCE2, con algunas revisiones al original

2.2. Roles de PRINCE2

Funciones y Responsabilidades de la Organizacin del Proyecto.
PRINCE2 se basa en un entorno cliente / proveedor, y la organizacin del tema
define y establece la estructura del proyecto de roles y responsabilidades.
PRINCE2 no define puestos de trabajo asignados a las personas, sino ms
bien, que define los roles, cada uno con un conjunto de responsabilidades.
Cada funcin puede tener una persona o varias personas de llenado que, un
individuo puede cumplir ms de una funcin.
Lo que es importante es que las personas adecuadas se eligen para cada uno
las funciones y responsabilidades, y esto incluira a los conocimientos,
habilidades, experiencia, autoridad, credibilidad, compromiso del individuo y de
la disponibilidad.
PRINCE2 tiene un trmino reservado para la junta del proyecto, director del
proyecto, y algunas funciones y responsabilidades opcionales, y este trmino
se llama el Equipo de Gestin del Proyecto. Un proyecto PRINCE2 siempre
tiene tres categoras primarias de las partes interesadas, y estos roles y
responsabilidades siempre se debe incluir si el proyecto ha de tener xito.
Los tres intereses principales que conforman las funciones y responsabilidades
del consejo de proyecto son los intereses de negocios - el Caso de Negocio
5

debe proporcionar un valor para el dinero, el inters del usuario - stos usarn
los resultados del proyecto, ya sea para darse cuenta de los beneficios, que
puede operar, mantener o apoyo los resultados de los proyectos, y estas salidas
tendrn un impacto en ellos, y el inters del proveedor - stos suministran los
recursos y habilidades para producir productos de un proyecto.

Hay

cuatro

niveles

de

un

proyecto

PRINCE2

funciones

responsabilidades de la organizacin
1. La gestin corporativa o del programa, las cuales exceden del equipo de
gestin de proyectos, y son responsables del Mandato de Proyecto,
nombrar al Ejecutivo, y la definicin de los lmites de tolerancia a nivel de
proyecto.
2. La Junta del Proyecto es responsable de proporcionar la direccin
general y son responsables del xito del proyecto
3. El Jefe de Proyecto es responsable de la gestin del da a da del
proyecto dentro de las limitaciones establecidas por la Junta del
Proyecto.
4. Los miembros del equipo son responsables de la entrega de los
productos del proyecto en calidad, tiempo y costo.
Entre las funciones y responsabilidades de la Junta del Proyecto incluyen ser
responsable del xito o fracaso del proyecto, proporcionando direccin
unificada, proporcionando los recursos y la autorizacin de la financiacin del
proyecto, y la garanta de la toma de decisiones eficaz.
La junta del proyecto debe tener el nivel adecuado de autoridad, ser crebles,
tienen la capacidad de delegar, y estar disponible para siempre que se
necesitan decisiones y direcciones.
Las funciones y responsabilidades del Proyecto Junta Ejecutiva son
responsable en ltima instancia para el xito del proyecto y tiene el derecho de
6

veto en cualquier toma de decisiones. El ejecutivo es responsable del caso de

negocio.
Las funciones y responsabilidades de los usuarios senior representan
aquellos que usarn los productos del proyecto y tambin los que van a utilizar
los productos para lograr un objetivo o entregar beneficios. El mayor usuario
especifica los beneficios y se lleva a cabo para dar cuenta de la gestin
corporativa o del programa.
El papel Proveedor Superior representa a los que va a disear, desarrollar,
facilitar, adquirir y aplicar los productos del proyecto. Este papel es responsable
de la integridad tcnica del proyecto.
Cada miembro de la Junta del Proyecto es responsable de su propia seguridad,
los negocios, el usuario y el proveedor. En conjunto, esta funcin se llama
Proyecto de Garanta. Cada miembro de la junta del proyecto puede llevar a
cabo su propio proyecto de aseguramiento, o pueden optar por delegar.
Funciones y responsabilidades de garanta del proyecto deben ser
independientes de la Gerente del Proyecto y el equipo y tambin son
responsables de apoyar el director del proyecto, dando consejos y orientacin.
Si es probable que tenga muchas solicitudes de cambio del proyecto, a
continuacin, la junta del proyecto durante la etapa de iniciacin, tiene que
decidir si tienen el tiempo para tomar decisiones sobre estos cambios, o si
desean establecer una Autoridad de cambio que actuar en su nombre. Ellos
tendran que estar de acuerdo a "reglas de enfrentamiento".
Por ejemplo, la junta del proyecto slo puede hacer frente a los cambios por
encima de cierto valor monetario. La Junta del Proyecto tambin podra
considerar la asignacin de un presupuesto separado a pagar por tales
cambios.
La Junta del Proyecto no debe exceder de seis a ocho personas por lo dems
la toma de decisiones pueden ser lentos, es una buena idea considerar la
7

posibilidad de reuniones con proveedor fuera de lnea y el usuario, y traer un

representante de nuevo a la junta del proyecto para actuar en su nombre.
El proyecto de las funciones y responsabilidades del Gestor es responsable de
la gestin del da a da del proyecto y delegar la responsabilidad de la creacin
de productos para el director del equipo o los propios miembros del equipo de
especialistas.
Las funciones y responsabilidades del gestor de equipo si son nombrados, a
continuacin, el director del proyecto da los paquetes de trabajo para el director
del equipo, y el director del equipo dar al director del proyecto informes de
Checkpoint. Por ello, el director del equipo llevar a cabo la gestin diaria de
los miembros del equipo.
Otra funcin opcional es el uso de Apoyo a Proyectos. Funciones y
responsabilidades de este grupo proporcionarn servicios administrativos con
el proyecto, dar asesoramiento y orientacin sobre el uso de herramientas de
gestin de proyectos, y normalmente ofrecern gestin de la configuracin. Si
el Apoyo a los proyectos no est disponible, entonces lo har el director del
proyecto.
2.3 Estructura de PRINCE2
La estructura del mtodo PRINCE2 est organizada principalmente en cuatro
partes: principios, temas, procesos y tcnicas. Los componentes son reas de
conocimiento que deben aplicarse al proyecto cuando corresponda, los
componentes son implementados mediante los procesos, que son los
elementos que explican qu debe ocurrir y cundo a lo largo del ciclo de vida
del proyecto. Las tcnicas ofrecidas son mtodos de trabajo de uso opcional
pero muy recomendable.
PRINCE2 define 7 principios, 7 temas, 7 procesos y 2 tcnicas:
Principios
Pasamos a enumerar los principios fundamentales de Prince2.
8

1. Justificacin comercial continua a travs de un modelo de negocio

o business case, durante todo el ciclo de vida.
2. Aprender de la experiencia durante todo el ciclo de vida (Ante
partum, per totam vitam, post mortem)
3. Roles y responsabilidades definidos en una estructura organizativa
acorde

con

los

intereses

comerciales

de

promotores

patrocinadores, clientes y usuarios, socios y proveedores, adems

de directores funcionales y equipo directivo del proyecto.
4. Gestin del proyecto por fases a travs de un plan de proyecto y
planes para las siguientes fases: Pre proyecto, Inicio, Entrega(s) y
Final y Post Proyecto.
5. Gestin por excepcin (por delegacin de autoridad) en los niveles
de direccin, gestin y entrega.
6. Enfoque en los productos (en definicin y entrega de resultados) a
travs de descriptores de productos (EDT).
7. Adaptacin de mtodos y controles de gestin a los parmetros del
entorno de proyecto: propsito, tamao, complejidad, importancia,
capacidad y riesgo.
Temas
- Proceso de Negocio (Business Case).
El propsito es establecer mecanismos para juzgar continuamente si el
proyecto se ajusta al modelo de negocio, si se justifica comercialmente.
El Business Case (BC) describe los resultados intermedios, el resultado
final y el beneficio del proyecto.
Ajustado al tipo de proyecto, es dinmico y sirve para juzgar
continuamente si el proyecto es deseable, viable y alcanzable.

El enfoque del BC obliga a resumir razones, alternativas, beneficios,

prdidas, calendario, costes, riesgos y recuperacin del proyecto.
Desarrollar, el BC Preliminar (Pre proyecto) y el BC Detallado (Inicio).
Mantener, actualizada la versin en vigor del BC:

Verificar el BC valorndolo al principio de cada fase de entrega.

Mantener el BC actualizado dentro de cada fase de entrega.

Confirmar los beneficios, evaluando el BC al final de cada fase

de entrega, en la fase final y en la fase post-proyecto.

- Organizacin (Organization).
En un entorno cliente/proveedor, el propsito es definir y establecer la
estructura de responsabilidades y delegacin del equipo de gestin del
proyecto.
La definicin obliga a considerar los roles y responsabilidades de
diversos actores.
Las asignaciones de tres directivos: Proyecto, Programa y Corporacin.
Los intereses de tres actores principales: corporativos o comerciales, de
clientes o usuarios y de proveedores o agentes.
El enfoque obliga a considerar 4 niveles organizativos:

Corporacin (EP).

Direccin (JP).

Gestin (PM).

Entrega (TM).

En esta temtica hay que asignar roles y responsabilidades a los

numerosos agentes y actores tales como:

10

Alta direccin.

Directores funcionales.

Ejecutivo patrocinador.

Junta de Proyecto.

Garanta de Intereses.

Autorizacin de Cambios.

Usuarios principales.

Proveedores principales.

Director del proyecto.

Lderes del equipo.

Miembros del equipo.

Apoyo al proyecto.

Capas de la Organizacin del Proyecto

Capa 1. Gestin corporativa

Esta capa de gestin se ocupa de la estrategia del negocio y
proporciona una visin de lo que la empresa debe parecer y lo que
debera estar haciendo en el futuro. Un proyecto determinado puede
formar parte de un programa mucho ms grande o de una inversin
11

importante de una empresa, por tanto la gestin corporativa es la clave

de la gestin de la empresa.
Esta capa se encargar de coordinar todos los proyectos que se
encuentran en marcha en la empresa y de enfocarlos adecuadamente
segn su visin de la empresa. Dada la cantidad de trabajo que esto
representa, la gestin corporativa no se encarga de gestionar los
detalles de los proyectos, para ello delegan esta tarea en las juntas de
decisin de los proyectos.
Pese a la delegacin de tareas, la gestin corporativa mantiene control
sobre los productos, el mbito y las restricciones de los proyectos,
fijando la frecuencia con la cual quieren recibir informes de progreso por
parte de las juntas de proyecto.
La definicin de las metas del proyecto para esta capa se ver en
trminos de fechas de entrega y presupuestos. Proporcionan a las
juntas de proyecto los lmites de presupuesto y tiempo, cualquier
desviacin del proyecto en estos trminos deber serles comunicada.

Capa 2. Junta de decisin del proyecto

Esta capa, como vimos en la seccin 2.2 Roles en PRINCE2, se
encarga de tomar las decisiones importantes sobre el proyecto que
exceden los lmites de autoridad del jefe de proyecto.
Entre sus funciones estn monitorizar la correcta comprensin por parte
del jefe de proyecto de los requisitos del proyecto, la viabilidad del
proyecto, estudiar que la solucin propuesta sea coherente con la
estrategia de la empresa, monitorizar retrasos y presupuestos y
considerar si merece la pena seguir con el proyecto.

12

Tomando los lmites generales fijados por la gestin corporativa, la junta

de proyecto fija los lmites de desviacin de tiempo y presupuesto para
cada etapa del proyecto, de forma que el jefe de proyecto no podr
traspasarlos sin informar y pedir autorizacin a la junta.
Asimismo, el jefe de proyecto deber pedir autorizacin para moverse
de una etapa a la siguiente, proporcionando informes de progreso con
la frecuencia prefijada por la junta de decisin

Capa 3. Jefe de proyecto

Esta capa se corresponde con el rol de jefe de proyecto, se encarga de
la planificacin, control y monitorizacin del da a da del proyecto.
Dado que normalmente el jefe de proyecto no es el que proporciona los
fondos para la inversin en el proyecto, se ver a menudo limitado en el
mbito de sus decisiones, teniendo que acudir frecuentemente a las
capas superiores para la toma de decisiones importantes, la asignacin
de recursos y presupuesto y la aceptacin del trabajo.
Cuanto mayor sea el proyecto, ms probable ser que el jefe de
proyecto est limitado en cuanto a las decisiones que pueda tomar.
En caso de la existencia de equipos de trabajo, es el jefe de proyecto el
encargado de recibir los informes de progreso regularmente y de
monitorizar la calidad del trabajo que producen los equipos.

Capa 4. Jefe de equipo

Esta capa es opcional y a su vez corresponde tambin con el rol de jefe
de equipo.

13

Existen dos casos en los que se requiere especialmente esta capa; uno
de ellos es aquel en el que para el desarrollo del proyecto se requiera
conocimiento en campos muy diversos, que la cantidad de recursos sea
muy amplia o los equipos de trabajo estn geogrficamente dispersos.
El otro caso es aquel en el que la solucin sea proporcionada por un
proveedor externo, de manera que esta tercera parte gestionar sus
propios recursos.

Estructura de la Organizacin

14

- Planes (Plans).
El propsito es definir los medio a para entregar los productos, (dnde,
cmo, quin, cundo y cunto) con el fin de facilitar la comunicacin y
el control.
Un plan se define como un conjunto de metas y medios, base del
sistema de informacin del proyecto, que se establecen por niveles:

Plan Corporativo o del Programa, Plan de la Fase de Inicio.

Plan de proyecto, Planes de Fase.

Planes de Equipo y Planes de Excepcin.

El enfoque consiste en determinar una serie de trabajos:

Para el Plan de Proyecto:

Descripcin del Producto.

Crear la Estructura Jerrquica de Productos (EJP).

Descripciones de Productos.

Diagrama de Flujo de Productos (cronograma general).

Para todos los planes:

Disear el Plan.

Definir y Analizar los Productos.

Identificar Actividades y Dependencias.

Preparar Estimaciones.

Preparar el Cronograma (detallado, analizar los riesgos.

Documentar el Plan.

- Riesgo (Management of Risk).

El propsito es identificar, valorar y controlar la incertidumbre y mejorar
las posibilidades de xito del proyecto.
15

Se

definen

tanto amenazas

como

oportunidades desde

tres

perspectivas:

Largo plazo o estratgica.

Medio plazo o tctica (del programa, del proyecto, etc.).

Corto plazo u operativa.

El enfoque, que se basa en los principios de la gestin establecidos en

la gua Management of Risks: Guidance for Practitioners (M_o_R)
recomienda crear, utilizar y mantener:

Estrategia de Gestin del Riesgo (plan), Registro de Riesgos.

Procedimientos

de

Gestin

de

Riesgos:

Identificacin,

Valoracin, Planificacin (de la respuesta), implementacin (de

la respuesta) y Comunicacin (supervisin y control).

El ciclo de la Gestin de Riesgos

16

- Calidad (Quality in a project environment).

El propsito es definir e implementar los medios con los que se crearn
y se verificarn productos de proyecto aptos para su uso.
La calidad es cumplimiento de los requerimientos, inherentes o
asignados, a un producto de forma que demuestre ser capaz de
satisfacer necesidades, expectativas y exigencias de cliente/usuario.

Se debe planificar y controlar (que incluye el aseguramiento de

la mejora) por el equipo de proyecto.

Se debe garantizar por un rgano independiente (Garanta de

Calidad) externo al proyecto.

El enfoque obliga a realizar las siguientes actividades:

Definir el alcance, es decir el producto y los productos del

proyecto, incluyendo sus expectativas de cliente y criterios de
aceptacin.

Describir los criterios de calidad en la Descripcin del Producto

del Proyecto y los Descriptores de Producto (EDT)

De acuerdo a una Estrategia de Calidad, hay que implementar y

supervisar

criterios

mtodos

de

calidad

nivel

de

componentes.

Registrar, documentando la revisin y aceptacin, tanto de

productos como de componentes.

- Gestin de la Configuracin (Configuration Management).

Proporciona al equipo de gestin del proyecto el control necesario para
la validacin del proyecto y es vital para el sistema de calidad. Este
componente suministra los mecanismos para las cuestiones de
trazabilidad del proyecto.
17

- Control del Cambio (Change Control).

El propsito es identificar, evaluar y controlar cualquier cuestin y/o
cambio, potencial o aprobado, que pueda afectar o afecte a alguna
referencia (baseline).

Cuestiones, cualquier evento no planificado que sea necesario

gestionar.

Cambios, cualquier propuesta o solicitud formal.

El procedimiento de control de cambios define los mtodos para

registrar (identificar), examinar (valorar), proponer, decidir (aprobar,
rechazar o postergar), implementar y verificar cambios y cuestiones.
Debe incluir un procedimiento de gestin de la configuracin o control
de versiones (releases), tanto de productos como de componentes.
El enfoque se basa en el establecimiento de una Estrategia de la
Configuracin y de varios de los productos documentales descritos en:

Fichas de Elementos de la configuracin

Informe sobre el Estado de los Productos.

Archivo Diario, Registro de Cuestiones.

Informe de Cuestiones (solicitud de cambio).

Procesos
Los 7 procesos se alinean con las fases del ciclo de vida del proyecto y
los niveles de gestin.
Cada proceso se describe mediante su:

Propsito

Objetivo

Contexto

Actividades
18

Cada

actividad

se

desglosa

en

varios

productos

acciones

recomendadas que se asignan a los diferentes roles mediante una tabla

de responsabilidades.
Cada proceso se diagrama mediante una serie de smbolos (procesos,
actividades, desencadenantes y productos).
Directing a Project es un proceso muy largo que ocupa toda la tabla y
ocupa todo el ciclo de vida, luego los procesos son diferentes del ciclo de
vida en PRINCE2 y tambin en PMBOK.
Solo hay un proceso que se aplica en la etapa pre-proyecto que se llama
SU (Starting up a Proyect), hay otros procesos que se repinten en las
interfaces llamados SB (Stage Boundary) o procesos de intercambio entre
fases, estos procesos presuponen que hay un ciclo de vida, que son un
conjunto de fases, el PRINCE2 no define da por supuesto que un proyecto
tiene un pre-proyecto, luego tiene una etapa de iniciacin, una etapa de
entregas Subsequent Delivery Stage(s) y una etapa de entrega final (Final
Delivery Stage).
Ni en las temticas y ni en los procesos de PRINCE2 se habla del
ciclo de vida.
Los procesos como hemos visto son siete: Directing a Project es
continuo a lo largo de todo el ciclo de vida. Starting up a Proyect (SU)
en la etapa pre-proyecto. Cada vez que se cambia de etapa (o
intercambio de etapa, aqu uno coge la temtica de Business Case y
estudia si el proyecto sigue teniendo sentido continuar) se hace Stage
Boundary (SB) una gestin de las interfaces entre etapas. Hay otro
proceso que solo se hace en la etapa de inicio Initiating a Project (IP), y
luego dentro de cada etapa o fase de ciclo de vida se aplican dos
procesos: Controlling a stage (Control de la Fase) y Managing Product
Delivery (Gestin de la entrega del producto), un ltimo proceso Closing
a Project (CP) solo se aplica una vez al final de todo el ciclo de vida.
19

Los procesos de PRINCE2 son Macro-Procesos y los de PMBOK son

Micro-Procesos.
Es curioso que un proyecto se lance con una preparacin SU y un inicio
IP y se cierre con un nico proceso CP.
Los procesos de PRINCE2 son diferentes, son Macro-Procesos, los
procesos de PMBOK son Micro-Procesos en el sentido de que se aplican
sistemticamente en todas las etapas, en todas las fases de un ciclo de
vida, sin embargo en PRINCE2 en un ciclo de vida solo se aplican dos: el
Controlling a Stage y el Managing Product Delivery. Cuando hablamos de
Macro-Procesos o procesos continuos como el DP o procesos que nacen
y mueren en situaciones muy concretas como el SB o procesos que se
hacen al principio SU o IP o al final CP.
PRINCE2 relaciona todos los procesos con el Directing a Project (DP),
incorpora en su metodologa el gobierno, la gestin y la entrega:

Directing: corresponde al nivel de gobierno.

Managing: nivel ejecutivo o gestin.

Delivering: nivel de entrega, tcnico, nivel cercano al producto.

La mitad de los procesos estn en la fila Managing, que es el nivel del

Project Management pero el mtodo incorpora el proceso continuo que
hace el Sponsor en PMBOK y aqu se llama el ejecutivo (junta de
proyecto, comits de garantas en PRINCE2) y que en la preparacin del
proyecto, que es el primer proceso SU, hay un enlace entre el nivel de
gestin y nivel directivo. En las decisiones de lanzar un proyecto son a
alto nivel, el SU se coloca en el nivel superior pero depende mucho de los
detalles, de la capacidad ejecutiva de los directores, es decir, se ajusta
en los niveles superior e intermedio. Lo mismo ocurre en los macroprocesos: quien los ha ejecutado y quien se encarga de ellos. En todos
ellos interviene el PM pero la responsabilidad por ejemplo del Directing
las tiene el nivel de gobierno donde el PM acta bsicamente como
20

asesor. El nivel de delivery est en manos de los Team Leaders y el nivel

autentico del PM se aglomera en el Stage Boundary (SB), Initiating a
Project (IP), Closing a Project (CP), Controlling a Stage.
El mtodo descripcin de estos procesos es el siguiente, se describe el
propsito, los objetivos, el contexto y las actividades pero en principio
variaran los responsables de ejecutarlos y el propsito es muy diverso, no
es dirigir en el caso del DP es gobernar, y en caso del Delivery es hacer
la entrega.
A continuacin se describe cada uno de los procesos de PRINCE2:
- [SU] El Proceso de Puesta en Marcha (Starting Up a Project).
El propsito es que la Junta de Proyecto pueda aprobar el inicio de
proyectos viables y que valgan la pena para la corporacin.
Los objetivos principales son asegurar la justificacin comercial del
proyecto mediante un Modelo de negocio e informacin suficiente sobre
sus alternativas y alcance mediante un Expediente de Proyecto.
El contexto implica recibir el mandato de la Junta de Proyecto de darle
informacin suficiente para encomendar el Inicio del Proyecto.
Las actividades del proceso son:
1. Nombrar al Ejecutivo y Project Manager.
2. Registrar lecciones anteriores.
3. Disear y nombrar el equipo de gestin del proyecto.
4. Preparar del Modelo de Negocio preliminar.
5. Seleccionar el enfoque de proyecto y elaborar el Expediente de
Proyecto.
6. Planificar la fase de inicio.

21

- [DP] El Proceso de Direccin de Proyecto (Directing a Project).

El propsito es facilitar que la Junta de Proyecto tome las decisiones
clave y ejerza el control general del proyecto.
Los objetivos principales es que haya una autoridad para:
Iniciar el proyecto
Entregar los productos del proyecto
Cerrar el proyecto.
El contexto implica dar protagonismo formal a la Junta de Proyecto
como enlace entre el Director del Proyecto y la alta direccin.
Las actividades del proceso son:
1. Autorizar el Inicio del Proyecto.
2. Autorizar el Proyecto.
3. Autorizar un Plan de Fase o de Excepcin.
4. Proporcionar direccin ad hoc.
5. Autorizar el Cierre de Proyecto.
6. Cada actividad se describe en un grfico de desencadenantes y
resultados y en una tabla con productos, acciones, productos y
responsabilidades relacionados con el proceso.

- [IP] El Proceso de Inicio del Proyecto (Initiating a Project).

El propsito es establecer bases slidas para el proyecto procurando
que la organizacin entienda el esfuerzo a realizar antes de
comprometerse a asumirlo.
Los objetivos principales son asegurar una comprensin comn acerca
de las razones, beneficios y riesgos del proyecto, as como acerca de

22

su alcance, productos deseados, trabajos a realizar y decisiones a

tomar.
El contexto implica que debemos conseguir que la Junta de Proyecto
autorice conscientemente el proyecto a travs de una Documentacin
de Inicio de Proyecto.
Las actividades del proceso son:
1. Preparar la Estrategia de Gestin del Riesgo.
2. Preparar la Estrategia de Gestin de la Configuracin.
3. Preparar la Estrategia de Gestin de la Calidad.
4. Preparar la Estrategia de Gestin de la Comunicacin.
5. Establecer los Controles del Proyecto.
6. Crear el Plan de Proyecto.
7. Perfeccionar el Modelo de Negocio.
8. Preparar la Documentacin de Inicio de Proyecto.

- [CS] El Proceso de Control de Fase (Controlling a Stage).

El propsito es asignar y supervisar el trabajo a realizar informando a la
Junta de Proyecto acerca del progreso y la calidad de los mismos, as
como de las rectificaciones propuestas, aprobadas e implementadas.
Los objetivos principales son:
1. La entrega de los productos dentro de las tolerancias
establecidas.
2. Revisar continuamente el modelo de negocio.
3. Mantener bajo control riesgos y cuestiones.
El contexto implica que el Director del proyecto utilice los Paquetes de
Trabajo como puntos de control de todos los trabajos autorizados.

23

Las actividades del proceso son:

1. Autorizar un Paquete de Trabajo.
2. Revisar el estado del Paquete de Trabajo.
3. Recibir el Paquete de Trabajo completado.
4. Revisar el estado de cada fase.
5. Informar sobre el desarrollo.
6. Registrar y examinar cuestiones y riesgos.
7. Presentar excepciones relativas a cuestiones y riesgos.
8. Llevar a cabo rectificaciones.

- [MP] El Proceso de Gestin de Entrega (Managing Product Delivery).

El propsito es establecer requisitos formales para acordar, completar y
entregar todos los trabajos del proyecto.
Los objetivos principales son:
1. Acordar.
2. Autorizar.
3. Realizar.
4. Completar.
5. Entregar todos los Paquetes de Trabajo del proyecto.
El contexto implica gestionar la conexin entre el Director del Proyecto
y los Directores de Equipo de forma que todos los productos se
entreguen cumpliendo las expectativas y dentro de las tolerancias
acordadas.
Las actividades del proceso son:
1. Aceptar un Paquete de Trabajo (acordar).
2. Ejecutar un Paquete de Trabajo (completar).
3. Entregar un Paquete de Trabajo.
24

- [SB] El Proceso de Gestin de Lmites de Cada Fase (Managing Stage

Boundaries).
El propsito es posibilitar que, cuando el final de la fase en curso sea
inminente, la Junta de Proyecto revise el desarrollo de la fase en curso
y apruebe el plan de las fases siguientes.
Son objetivos adicionales:
1. Revisar el Plan de Proyecto actualizado.
2. Confirmar la vigencia de la justificacin comercial del Modelo de
Negocio.
El contexto implica elaborar y solicitar de la Junta de Proyecto la
aprobacin de un Plan de Excepcin si se considera que el Plan de
proyecto 0 el Plan de la Fase no se pueden cumplir.
Las actividades del proceso son:
1. Planificar la fase siguiente.
2. Actualizar el Plan de Proyecto.
3. Actualizar el Modelo de Negocio.
4. Informar sobre el final de fase.
5. Elaborar un Plan de Excepcin.

- [CP] El Proceso de Cierre del Proyecto (Closing a Project).

El propsito es proporcionar un punto final de control en el que se
confirme la aceptacin del Producto del Proyecto y se reconozca que se
han alcanzado los objetivos establecidos en la Documentacin de Inicio
de Proyecto, son objetivos adicionales:
1. Verificar la aceptacin de los productos por los usuarios de los
mismos.

25

2. Asegurar el soporte de productos y usuarios por parte de la

organizacin.
3. Revisar el rendimiento del proyecto.
4. Evaluar los beneficios conseguidos.
5. Registrar el aprendizaje adquirido.
El contexto implica transferir la propiedad de los productos completados,
tanto si el proyecto se ha completado como si se ha cancelado,
planificando el proceso de cierre adecuada y detalladamente.
Las actividades del proceso son:
1. Preparar el cierre planificado.
2. Preparar el cierre prematuro.
3. Entregar los productos.
4. Evaluar el proyecto.
5. Recomendar el cierre del proyecto.

26

Tcnicas
- Planificacin en Base al Producto (Product-based planning).
Es un mtodo que centra la planificacin, las tareas del jefe de proyecto
y de todos los que participan en el proyecto mismo, se concentra en la
descripcin de los productos o entregables del proyecto por sus criterios
de calidad, por su tolerancia de calidad y planifica antes de planificar las
tareas los productos, los resultados.
La planificacin basada en productos es fundamental en PRINCE2 y es
muy recomendable llevarla a cabo. Existen dos razones principales para
darle este enfoque a la planificacin del proyecto: en primer lugar, un
proyecto genera productos, no actividades; en segundo lugar, la calidad
de un producto es medible, mientras que la calidad de una actividad slo
puede ser medida por su resultado, es decir, el producto.
La planificacin basada en productos tiene tres componentes:

Estructura de desglose del producto.

Descripcin de los productos.

Diagrama de flujo del producto.

Estructura de desglose del producto

Una estructura de desglose del producto es una jerarqua de los
productos que el plan tiene que producir.
En la parte superior de la jerarqua encontramos el producto final. De
esta manera, se desglosa en sus componentes principales en el
siguiente nivel. Cada componente se divide a su vez en partes y el
proceso contina hasta que el responsable de la planificacin alcanza
el nivel deseado de detalle para la planificacin.

27

Descripcin del producto

Para cada producto identificado, se escribe una descripcin para todos
los niveles de la estructura de desglose. Su creacin fuerza al
responsable de la planificacin a considerar si se sabe suficiente sobre el
proyecto para planificar su produccin.
Este momento es tambin la primera vez en la que se toma en
consideracin la calidad del producto. Los criterios de calidad indicarn
cuntos y qu tipo de verificaciones de calidad se requerirn.
Los propsitos son proporcionar una gua:

Para el responsable de la planificacin sobre la cantidad de

esfuerzo necesario para crear el producto.

Para el autor del producto, diciendo lo que se necesita.

Para comparar y medir el producto final.

Estas descripciones son vitales para hacer las verificaciones de calidad

de los productos relacionados. Las descripciones deberan contener:

El propsito del producto.

Los productos de los que se derivan.

La composicin del producto.

Cualquier estndar para formato y presentacin.

Los criterios de calidad que se le aplicarn al producto.

Los mtodos de verificacin de calidad que se utilizarn.

La descripcin del producto se le entregar al creador y a aquellos

que deban realizar las verificaciones de calidad.

28

Estructura de desglose de un producto.

Diagrama de flujo del producto

El diagrama de flujo del producto es un diagrama que muestra la
secuencia en la cual los productos tienen que ser desarrollados y las
dependencias entre ellos. Se hace despus de la estructura de desglose
del producto.
El diagrama de flujo del producto necesita normalmente slo dos
smbolos: un rectngulo que contiene el producto y una flecha para
mostrar las dependencias.

29

Diagrama de flujo del producto.

30

Dependencias externas
Existen casos en los que el producto que desarrolla el proyecto depende
de la entrega de otro producto sobre el cual no se tiene control. Por tanto
necesitamos un mtodo para representar estas dependencias externas.
En la estructura de desglose del proyecto se representan estos productos
de los cuales el proyecto es externamente dependiente con un smbolo
diferente, por ejemplo una elipse.

Dependencias externas.

Productos de gestin
Es muy importante tener en cuenta que la gestin del proyecto genera
estos productos de gestin, as como los productos tcnicos o especiales
que tiene como objetivo principal el proyecto.
Estos productos de gestin cuestan un esfuerzo y deben ser planificados
al igual que los productos tcnicos. Estos productos de gestin son muy
parecidos para todos los proyectos.
31

A continuacin podemos observar dos ejemplos de las estructura de

desglose de los productos de gestin.

Ejemplo de estructura de desglose del producto.

Ejemplo 2 de estructura de desglose del producto

32

- Revisin de la Calidad (Quality review).

La revisin de la calidad es un mtodo de equipo para verificar la calidad
de un producto mediante un proceso de revisin. Su propsito es
inspeccionar un producto buscando errores de una manera planificada,
independiente, controlada y documentada y asegurarse de que todo
error encontrado se arregla.
Esta tcnica es una forma estructurada de revisar productos; debe
utilizarse

con

sentido

comn

para

evitar

una

aproximacin

extremadamente burocrtica, pero con la intencin de seguir los

procedimientos establecidos.
La meta principal es mejorar la calidad del producto; adems hay otros
objetivos menores que el primero, como son:

Encontrar errores lo antes posible.

Alentar el concepto de que los productos sean del grupo de

trabajo, en vez de responsabilidad de una sola persona.

Mejorar los datos de estado del producto.

Monitorizar el uso de estndares.

Difundir el conocimiento del producto entre aquellos cuyo propio

producto puede interactuar con el otro.

La documentacin de revisin de la calidad, cuando se guarda en el

archivo de calidad, proporciona, junto con el registro de calidad, una
relacin indicando que el producto fue inspeccionado, que los errores
encontrados se corrigieron y que las propias correcciones fueron
revisadas.

33

Personas involucradas
Los intereses de las partes que deben ser tenidas en cuenta cuando se
prepara la lista de asistentes sern:

El fabricante autor del producto.

Aquellas personas del equipo de monitorizacin del proyecto en

las que la junta haya delegado responsabilidades.

El cliente.

Personal que mantendr u operar con el producto terminado.

Personal cuyo trabajo se ver afectado por el producto.

Especialistas en las reas relevantes del producto.

Representantes de los estndares.

Roles presentes en la revisin de calidad

El fabricante, que es el autor del producto que se somete a revisin. Este
rol est presente para asegurar que todos los revisores tienen toda la
informacin requerida para llevar a cabo su trabajo. El fabricante deber
responder a las preguntas sobre el producto hasta que se tome una
decisin de si hay error o no; posteriormente llevar a cabo la correccin
de los errores. El fabricante no tiene permitido tomar una posicin
defensiva con respecto al producto.
El moderador, cuya funcin es proporcionar una actitud abierta y objetiva.
Debe tener los siguientes atributos:

Suficiente autoridad para controlar la revisin.

Comprende perfectamente el proceso de revisin de calidad.

Tiene experiencia como moderador.

34

El moderador tiene como responsabilidad asegurar que la revisin de

calidad est correctamente organizada y se lleve a cabo sin problemas
durante todas sus fases.
Para la fase de preparacin se debe verificar los procedimientos
administrativos que se han llevado a cabo y que las personas adecuadas
hayan sido invitadas.
Los revisores, que deben ser competentes para evaluar el producto desde
sus puntos de vista particulares.
Un secretario, alguien que tome nota de las acciones acordadas. Este rol
es asumido a menudo por personal del equipo de asistencia del proyecto.

Fases
Existen tres fases distintas dentro del procedimiento de Revisin de la
Calidad: preparacin, revisin y seguimiento.
Fase 1 Preparacin
El objetivo de esta fase es examinar el producto sometido a revisin y
crear una lista de preguntas o posibles errores para la revisin.
El moderador verifica con el fabricante que el producto est listo para
este momento, en caso negativo se avisa al jefe de proyecto y se
actualiza el plan de etapa. El moderador se asegura de que el equipo
de revisores est acordado y de que estarn disponibles en el
momento de la reunin.
Se enva la invitacin que contiene el lugar y la fecha de la revisin,
junto con copias del producto y las descripciones de producto
relevantes. Esto debe hacerse con suficiente antelacin como para

35

permitir a los revisores examinar el producto y escribir una lista de

preguntas para el fabricante.
Esta lista de preguntas se debe enviar al fabricante si es posible antes
de la reunin, el moderador y el fabricante deberan revisarla para que
el moderador pueda establecer los puntos de la reunin de revisin y
asignar un tiempo aproximado a cada uno.

Preparacin de la revisin de calidad.

Fase 2 Revisin
El objetivo de la revisin es acordar una lista de acciones necesarias
para corregir o completar el producto. El moderador y el fabricante no
tienen que fijar estas acciones en la reunin, es suficiente con acordar
que un rea particular necesita correccin o al menos una reevaluacin.
Al final de la reunin se fija la fecha para la cual debe estar lista cada
accin de correccin. El moderador decide uno de los siguientes tres
trminos para la reunin:

36

El producto est libre de errores.

El producto ser aceptable cuando se completen las acciones

de correccin acordadas en la reunin.

Se requiere tanto trabajo de correccin que el producto entero

debe ser revisado de nuevo.

Si se resuelve la reunin en el ltimo caso, se debe avisar al jefe de

proyecto para que se pueda actualizar el plan de etapa. Se actualiza
el registro de calidad y la recopilacin de todos los documentos se
guarda en el archivo de calidad.
Las preguntas de los revisores, las copias del producto con las
anotaciones del revisor y cualquier otro documento relevante es
recopilado por el moderador y entregado al fabricante para ayudarlo
con el seguimiento.

Fase 3 Seguimiento
El objetivo de la fase de seguimiento es asegurar que todas las
acciones contenidas en la lista de acciones se lleven a cabo.
El fabricante se lleva la lista de acciones y evala, discute y corrige,
en caso necesario, cada error. Cuando se ha corregido un error, el
fabricante conseguir que la tarea se elimine de la lista de acciones al
comunicrselo al revisor que propuso la correccin.
Cuando se han corregido todos los errores, el moderador confirmar
que el producto est completo y retirar la lista. Los documentos se
guardarn en el archivo de calidad y se actualizar el plan de etapa.

37

Seguimiento de la revisin de calidad.

2.4 PRINCE2 en cifras

Impacto de PRINCE2
Como vimos al comienzo de este documento, la metodologa PRINCE2 es un
estndar de facto con reconocimiento a nivel mundial. Junto con PMBOK son las
metodologas ms utilizadas e importantes del mundo.
Segn datos del Grupo ILX, organizacin acreditada de consultora y formacin
de metodologas tales como PRINCE2, este mtodo es el ms utilizado para la
gestin de proyectos en el mundo, siendo su tasa de crecimiento constante del
25% anual.
Esta entidad informa de que se realizan aproximadamente 420000 exmenes
anuales, reuniendo de 1500 a 2000 personas semanales para examinarse. Otro
dato importante es el ratio de mencin de dicha metodologa en las ofertas de
trabajo en el Reino Unido, esta cifra asciende al 70% de los anuncios.

38

Es muy importante mencionar que, entre los beneficios de esta metodologa,

encontramos que es la nica metodologa que acredita al individuo.
Aprendiendo PRINCE2
Como hemos visto, PRINCE2 es una de las metodologas que acredita al
individuo. Para ello, encontramos dos modalidades de examen:

Foundation Level Exam

Practitioner Level Exam

Foundation Level Exam

La primera modalidad de examen acredita los conocimientos de PRINCE2 del
individuo de forma que mida si el candidato ser capaz de actuar como un
miembro informado de un grupo de gestin de proyectos utilizando la
metodologa PRINCE2 en un proyecto que la implemente (ILX Group).
Este examen consta de 75 preguntas test y tiene una duracin de una hora. Es
un examen de libro cerrado, se necesita una puntuacin de al menos un 50%
para considerarse aprobado y los candidatos cuya lengua materna no sea el
ingls obtendrn tiempo extra para completarlo.
Practitioners Level Exam
Para acceder a esta modalidad de examen es necesario haber realizado
anteriormente y haber aprobado el examen de Foundation Level. Este examen
acredita que el candidato puede aplicar la metodologa PRINCE2 a la gestin
de un proyecto no complejo que se lleva a cabo en un entorno que implementa
PRINCE2 (ILX Group).
La duracin de este examen es de dos horas y media, consta de nueve
preguntas y se permite el uso del manual de PRINCE2. Es necesaria una
puntuacin del 55% para aprobar el examen y, al igual que en el anterior, se
conceder un tiempo extra para aquellos candidatos cuya lengua materna no
sea el ingls.
39

Cada examen tiene un coste aproximado de 300 y el grupo consultor ILX

considera que siguiendo un curso diseado por ellos, el nmero de horas
dedicadas para el aprendizaje de PRINCE2 consiste en unas 20 horas si el
candidato tiene experiencia previa en el campo, y de 40 a 60 horas si el
candidato no cuenta con experiencia previa.

Captulo 3
PRINCE2 frente a otra metodologa
3.1 PRINCE2 frente a PMBOK
Tanto PRINCE2 como PMBOK Guide son metodologas de gestin de proyectos
ampliamente aceptadas y utilizadas. El propsito de este apartado es estudiar
las principales diferencias entre ellas.
Definicin de proyecto
PMBOK: un proyecto es un esfuerzo temporal acometido para crear un
servicio o producto nico (PMI, 2000).
PRINCE2: un proyecto es un entorno de gestin creado con el propsito de
entregar uno o ms productos de negocio de acuerdo con un caso de negocio
especificado (OGC, 2002).

Propsito principal
PMBOK: su propsito principal es identificar aquel subconjunto del cuerpo de
conocimiento de la gestin de proyectos generalmente reconocido como
buenas prcticas.

40

PRINCE2: es un mtodo de gestin de proyectos. Una aproximacin

estructurada que se puede ajustar para utilizarse en cualquier tipo de
proyecto de cualquier tamao.

Estndar vs. Estndar de Facto

PMBOK:

PMBOK

Guide

es

un

estndar

de

IEEE

reconocido

internacionalmente (IEEE Std 1490-2003) que proporciona los fundamentos

de la gestin de proyectos que se aplican a una gran variedad de proyectos,
tales como construccin, software, ingeniera industrial, automocin, etc.
PRINCE2: es un mtodo estructurado para una gestin de proyectos efectiva.
PRINCE2 es un estndar de facto utilizado por el gobierno del Reino Unido y
ampliamente reconocido y usado en el sector privado, tanto en el Reino Unido
como internacionalmente.

Descriptivo vs. Preceptivo

PMBOK: es descriptivo, explica las tcnicas de gestin de proyectos a
utilizar.
PRINCE2: es preceptivo, explica cmo las tcnicas de gestin de proyectos
deberan ser estructuradas y aplicadas.

Procesos vs. Productos

PMBOK: est basado en procesos, es decir, el trabajo es realizado por los
procesos.
PRINCE2: est basado en productos, se centra en las entregas adecuadas
de productos en vez de en las actividades del proyecto.

41

Definicin de jefe de proyecto

PMBOK: el jefe de proyecto es la persona responsable de llevar a cabo y
lograr los objetivos del proyecto (PMI, 2000). El SEI (Software Engineering
Institute) lo define como el rol con la responsabilidad total sobre el proyecto
entero, el individuo que dirige, controla, administra y regula un proyecto y es
a la vez el responsable frente al usuario final (SWE).
PRINCE2: segn PRINCE2, el jefe de proyecto es la persona a la que se
confiere la autoridad y responsabilidad para gestionar el da a da del
proyecto, para entregar los productos requeridos dentro de las restricciones
acordadas con la junta de proyecto (OGC, 2002).
reas de Conocimiento y Procesos vs. Componentes y Procesos
A continuacin vemos grficamente las estructuras de PMBOK y de PRINCE2.
PMBOK

reas de Conocimiento del PMBOK.

42

Grupos de Proceso de PMBOK.

PRINCE2

Componentes de PRINCE2.

Procesos de PRINCE2.

43

En la figura que tenemos a continuacin se presentan las relaciones o

equivalencias que podemos encontrar entre las reas de conocimiento de
PMBOK y los componentes de PRINCE2.

Relacin de las reas de conocimiento de PMBOK con los componentes de PRINCE2.

44

Como vemos, en algunos casos tenemos reas de PMBOK que no estn

contempladas en PRINCE2 y otras que estn distribuidas en varios de sus
componentes y procesos combinados.
El caso del rea de recursos humanos, muy importante en PMBOK y en los
Estados Unidos, no se contempla especficamente en PRINCE2, por el contrario,
PRINCE2 incluye una descripcin detallada de las responsabilidades de los
roles del equipo de gestin del proyecto que se incluyen en la metodologa.
En la siguiente figura vemos la relacin existente entre los grupos de procesos
de PMBOK y los procesos de PRINCE2.

Relacin entre los grupos de procesos de PMBOK y los procesos de PRINCE2.

Como podemos observar, cada grupo de procesos de PMBOK se corresponde

aproximadamente con algunos de los procesos de PRINCE2.

45

Estructura
PMBOK: se centra en explicar las reas de conocimiento, que estn basadas
en funciones, haciendo nfasis en las entradas, las salidas, las herramientas
y las tcnicas.
PRINCE2: est basado en el ciclo de vida del proyecto, con seis de sus
procesos dedicados a este ciclo y dos de ellos (planificacin y dirigir un
proyecto) son continuos y concurrentes a lo largo del proyecto que sirven de
apoyo a los otros seis.

Etapa vs. Fase

PMBOK: la gua de PMBOK define una fase como: una coleccin de
actividades del proyecto lgicamente relacionadas, que normalmente
culminan con que un entregable importante se termina (PMI, 2000).
En PMBOK no se distingue entre fases y etapas, y en el texto oficial se utilizan
una u otra palabra indistintamente.
En PRINCE2 se habla de etapas en lugar de fases, se especifica que el uso
de etapas es obligatorio, si bien su nmero es flexible de acuerdo con los
requisitos de gestin del proyecto.
Tambin se diferencia entre etapas tcnicas y etapas de gestin. Las etapas
tcnicas se caracterizan por el uso de especialistas con determinadas
habilidades, mientras que las etapas de gestin sirven para la asignacin de
recursos y autoridad. Estas etapas, como vimos anteriormente, pueden
coincidir o no.

46

Contrato
PMBOK: reconoce que el proyecto necesita una evaluacin o estudio de
viabilidad, y debe ser la primera fase del proyecto. Difiere con otras
metodologas en el pensamiento de que la obtencin de las tcnicas de
gestin de proyectos es parte del proceso de gestin del proyecto en general.
PRINCE2: asume que el proyecto funciona dentro del contexto de un contrato
y no incluye esta actividad dentro del propio mtodo. Sin embargo, se sugiere
que, ya que las actividades de generar el contrato y obtenerlo son
especializadas, pueden llevarse a cabo separadamente utilizando tambin el
mtodo.

Documentacin
PMBOK: el equivalente para PMBOK del documento de iniciacin del
proyecto es el acta de constitucin del proyecto, la cual se produce como
salida del proceso de iniciacin, del rea de conocimiento de alcance de la
gestin del proyecto.
PMBOK define este acta como un documento emitido por la gestin senior
del proyecto, que autoriza formalmente la existencia del proyecto y
proporciona al jefe de proyecto la autoridad para asignar recursos a las
actividades del proyecto (PMI, 2000).
PRINCE2: esta metodologa suele generar bastante documentacin. El
primer documento al que se hace referencia es la peticin de proyecto, que
se genera en algn nivel de la organizacin con autoridad suficiente para
autorizar el uso de recursos y econmico. Debe contener suficiente
informacin para lanzar el proceso SU y en este proceso el documento se
convierte en el documento informe preliminar del proyecto.
Otra salida del proceso SU es el plan de la etapa de iniciacin.
47

Posteriormente se requerirn el documento de caso de negocio y el plan de

proyecto.
Esta documentacin, junto con las arriba mencionadas, se incluyen como
entradas para el proceso IP, que generar el documento de iniciacin del
proyecto. Este documento vital para el proyecto, ya que el progreso del
proyecto se medir con respecto a lo especificado en el PID.

Roles
PMBOK: en PMBOK no se definen los roles como en PRINCE2, el trabajo de
la puestos de trabajo y sus descripciones se deja al rea del conocimiento
llamada recursos humanos.
PRINCE2: PRINCE2 no define los puestos de trabajo de la gestin del
proyecto, en lugar de esto, define los roles que se necesitarn en el proyecto
de acuerdo a sus necesidades, ya que un mismo rol puede ser asignado,
compartido, dividido o combinado segn la necesidad.

Productos de Gestin
PMBOK: no contempla estos productos de gestin en su gua, salvo el
documento que recoge las lecciones aprendidas.
PRINCE2: en PRINCE2, como hemos visto anteriormente, existen los
siguientes productos de gestin: criterios de aceptacin, archivo de tems de
configuracin, registro de incidencias, registro de riesgos, registro de
lecciones aprendidas.

48

Planificacin
PMBOK: para PMBOK, la planificacin se ve generalmente como parte de
las habilidades generales de gestin claves (PMI, 2000), es uno de los cinco
grupos de procesos aplicado a cada fase, y por tanto es reconocido como un
esfuerzo continuado a lo largo de la vida del proyecto.
La esencia de la planificacin en PMBOK es crear un documento coherente
y consistente que pueda ser utilizado para guiar el proyecto y tambin como
lnea base para contrastar los cambios y controlarlos (PMI, 2000).
PRINCE2: la planificacin basada en productos es un punto clave de
PRINCE2, hace que la metodologa se centre en los productos que se tienen
que entregar y su calidad.
Forma parte integral del proceso de planificacin (PL) y lleva al uso de otras
tcnicas genricas tales como el uso de diagramas de Gantt.
Esta planificacin proporciona un marco de trabajo basado en productos que
se puede a cualquier proyecto, a cualquier nivel, y proporciona una secuencia
lgica para el trabajo del proyecto.
Un producto puede ser tangible como por ejemplo una mquina, un
documento, software; o puede ser intangible, como un cambio cultural o una
estructura organizacional diferente (OGC, 2002).

Control
PMBOK: en la gua, el control de cambios, al igual que la planificacin, se
estudia en la gestin de la integracin del proyecto, y es referenciado a lo
largo de muchas secciones.
PRINCE2: en PRINCE2, el control del trabajo tcnico se ejerce a travs de la
autorizacin de paquetes de trabajo. El control tiene el propsito de producir
49

los productos requeridos cumpliendo con los criterios de calidad definidos,

llevar a cabo el trabajo de acuerdo con un calendario, recursos asignados y
planes de costes y mantener siempre la viabilidad del proyecto vigilando y
contrastando el progreso.
El control por paquetes de trabajo se utiliza para asignar trabajo a
trabajadores individuales o a equipos, incluye controles de calidad, tiempo y
coste, e identifica la necesidad generar informes.
Los trabajadores o los equipos mantienen informado al jefe de proyecto a
travs de informes de puntos de control u otros mtodos acordados.

En el contexto de PRINCE2, se establece una distincin entre los trminos

tolerancia, contingencia y control de cambios.

Tolerancia es la desviacin permisible del plan, que el jefe de proyecto

puede permitir sin tener que llamar la atencin de la junta de proyecto
sobre el problema.

Contingencia es un plan que incluye medidas de tiempo y coste

necesarios para llevarlo a cabo y slo se emplear en caso de que
ocurra el riesgo asociado a dicho plan.

Control de cambios es un procedimiento designado para asegurar que

el procesamiento de todas las incidencias del proyecto est
controlado, incluyendo la entrega, anlisis y la toma de decisiones.

Existen muchas otras diferencias y matices entre las dos metodologas, ya

que ambas tienen enfoques totalmente diferentes de la gestin de proyectos.
Lo que propondremos a continuacin es un estudio sobre la forma en la que
ambas metodologas pueden ser combinadas para llegar a una metodologa
mejor y ms completa que tome lo mejor de ambas.

50

Captulo 4.
PRINCE2 a medida
En secciones anteriores hemos analizado los diferentes procesos y componentes
de PRINCE2 y se ha establecido que la metodologa es aplicable a cualquier tipo
de proyecto de cualquier tamao.
Este captulo lo dedicaremos a estudiar los posibles ajustes que se pueden realizar
para adaptar esta metodologa a proyectos de pequeo tamao. Hemos de tener en
cuenta que al ser PRINCE2 un marco de trabajo, la aplicacin de esta metodologa
es particular y diferente para cada organizacin, por tanto, los ajustes que
explicaremos sern simplemente directrices a seguir.
Un consejo generalizado por parte de expertos en la materia, indica que cada
organizacin debera reescribir su propia versin de PRINCE2, dejando en un
segundo plano los formularios y la documentacin recomendada para la
metodologa y ajustando adecuadamente los procesos internos ya establecidos en
la organizacin, dado que lo que optimizar el rendimiento de los proyectos ser un
buen ajuste de la metodologa al entorno de trabajo.
En este apartado veremos tambin las posibles variaciones y ajustes en los
componentes de PRINCE2 que se pueden aplicar, para beneficio de la
organizacin, cuando se trata de un proyecto de gran tamao.

4.1. Procesos de PRINCE2 aplicados a un proyecto de pequeo tamao

En esta seccin veremos las opciones de ajuste que ofrece PRINCE2 a nivel
de procesos para aplicar la metodologa a un proyecto de pequeo tamao.
Como ya hemos descrito en profundidad todos los procesos y subprocesos de
PRINCE2 en el segundo captulo de este documento, pasaremos directamente
a considerar los ajustes que se pueden realizar a nivel de subproceso.
Comenzar un proyecto (SU)
SU1 Designar una junta de proyecto ejecutiva y el jefe de proyecto.
En un proyecto pequeo, lo ms probable es que no se involucre a la gestin
corporativa con el proyecto. En este caso, es posible que el patrocinador sea
asignado como Ejecutivo y sea quien designe al jefe de proyecto
personalmente.

51

SU2 Disear un equipo de gestin del proyecto.

Los miembros de la junta de proyecto pueden ser los propios responsables de
monitorizacin y rendimiento. Frecuentemente, en proyectos muy pequeos, el
rol ejecutivo y los roles de usuario senior se combinan.
En el caso de que un departamento desarrolle un producto para su propio uso
y todos los recursos de dicho proyecto pertenezcan al mismo departamento,
entonces la persona que tenga el cargo de ejecutivo puede tomar tambin los
roles del proveedor senior y el usuario senior.
SU3 Designar un equipo de gestin del proyecto.
Puede no ser necesario obtener autorizacin de los niveles jerrquicos
superiores que no sean del ejecutivo y es posible que no sean necesarias las
funciones de la asistencia del proyecto.
SU4 Preparar el informe preliminar del proyecto.
En estos casos puede existir cierta presin por comenzar a realizar el trabajo
tcnico del proyecto lo antes posible, pero se debe evitar dejarse llevar por
estas prisas y realizar un buen estudio preliminar del proyecto, que llevar a
evitar desacuerdos posteriores sobre su alcance y posibilidades.
SU5 Definir la aproximacin al proyecto.
Se debe proceder de la misma forma en proyectos de cualquier tamao; la
presin por empezar con el trabajo tcnico puede llevar a presionar para no
llevar a cabo este proceso, pero esto se debe evitar a toda costa.
SU6 Planificar la etapa de iniciacin.
La puesta en marcha del proyecto puede tomar simplemente una hora o dos de
trabajo, y por tanto puede que no sea necesario un plan formal para ello.

Poner en marcha un proyecto (IP)

52

IP1 Planificar la calidad.

Incluso en el caso en el que el cliente deje los controles de calidad a cargo del
desarrollador, es muy importante establecer al menos las situaciones y pruebas
de calidad que el producto debe superar adecuadamente para ser aceptado.
IP2 Planificar el proyecto.
Puede ocurrir que no sea necesario producir los planes de etapa fsicamente
separados, si el plan de proyecto puede detallar suficientemente el da a da y
su control. Es el jefe de proyecto el que debe decidir si la inclusin de todos los
detalles hace al plan demasiado difcil de comprender en su totalidad.
IP3 Refinar el caso de negocio y los riesgos.
Es necesario realizar una verificacin de la viabilidad y las justificaciones para
comenzar un proyecto. El no comprobarlo adecuadamente en un principio
puede suponer prdidas en el presupuesto anual y posteriormente puede darse
la situacin de que no existan fondos suficientes para realizar un proyecto ms
grande y ms importante.
IP4 Establecer el control del proyecto.
Puede ser aceptable en algunos casos que los informes para la junta de
proyecto se den verbalmente, aunque se debe siempre mantener los informes
inicio y de fin formalizados.
IP5 Establecer los archivos del proyecto.
Es posible que un mtodo de gestin de la configuracin al completo no sea
necesario en caso de un proyecto pequeo, aun as se debe mantener al menos
algn tipo de control de versiones.
IP6 Ensamblar el documento de iniciacin del proyecto.
Para proyectos pequeos, la generacin de documentos de iniciacin de
pequeo tamao es adecuada, aun as, nunca deben suprimirse.

53

Dirigir un proyecto (DP)

DP1 Autorizar la puesta en marcha.
Es posible realizar este proceso informalmente, si la junta de proyecto lo
permite. La etapa de iniciacin puede ser tan corta que es posible que no se
requiera ningn informe.
DP2 Autorizar el proyecto.
Los detalles del documento de iniciacin pueden ser discutidos y acordados
informalmente en poco tiempo y puede ser suficiente que la junta de proyecto
autorice el comienzo cuando se presenten los ltimos documentos informativos.
Aun as, la autorizacin para comenzar debera confirmarse por escrito, ya que
es un documento importante para la gestin.
DP3 Autorizar una etapa o plan de excepcin.
Las decisiones se pueden tomar informalmente, pero aun as, la junta de
proyecto debera seguir los pasos establecidos en este proceso y debera
guardarse un registro de las decisiones tomadas.
DP4 Direccin a medida.
Puede resultar suficiente que la junta y el jefe de proyecto acuerden
informalmente las acciones a seguir con respecto a una incidencia, tan pronto
como haya sido documentada.
DP5 Confirmar el cierre del proyecto.
Puede que no sean necesarios todos los informes de cierre del proyecto, pero
aun as, debera existir un documento formal que establezca la autorizacin por
parte de la junta de proyecto para cerrar el proyecto.

Controlar una etapa (CS)

CS1 Autorizar un paquete de trabajo.
Se puede utilizar el mismo proceso si el trabajo se asigna a un trabajador
individual en vez de a un equipo, pero puede hacerse menos formalmente.
El jefe de proyecto debe considerar si se necesitar posteriormente un registro
del rendimiento personal o del equipo para posteriores evaluaciones. Si el jefe

54

de proyecto mismo es el que est realizando el trabajo no se necesitar este

proceso.
CS2 Evaluar el progreso.
En proyectos de pequeo tamao, los informes de punto de control pueden ser
verbales.
CS3 Capturar las incidencias del proyecto.
Las peticiones de cambio o fallos por parte del proveedor necesitan ser
documentados como parte del seguimiento de auditoras del proyecto, an en
aquellos de pequeo tamao.
CS4 Examinar las incidencias del proyecto.
El jefe de proyecto puede llevar a cabo el anlisis de impacto tan pronto como
la Incidencia se presente y tomar una decisin sobre la accin adecuada a
seguir.
En la prctica, es posible combinar los procesos de captura y de examen con
el de tomar acciones correctivas o el de elevar las Incidencias a la junta de
proyecto.
CS5 Revisar el estado de la etapa.
En proyectos de pequeo tamao, estas actividades son tambin necesarias.
El jefe de proyecto debe tomar decisiones sobre la frecuencia de las revisiones,
de acuerdo con la situacin del proyecto y su entorno.
CS6 Redactar informes sobre los temas ms relevantes.
Estos informes pueden ser verbales si la junta de proyecto est de acuerdo,
pero aun as, siguen siendo necesarios.
CS7 Tomar acciones correctivas.
Aunque sea un proyecto pequeo, sigue siendo importante registrar el porqu
de los cambios que se produjeron en los planes.
CS8 Elevar incidencias del proyecto.
La formalidad de este proceso est relacionada con la formalidad del proceso
CS6, ambos pueden ser informales y breves.
CS9 Recibir un paquete de trabajo terminado.
55

El grado de formalidad aplicada a este proceso est relacionado con el proceso

CS1, ambos pueden ser informales y breves.

Gestionar la entrega de productos (MP)

MP1 Aceptar un paquete de trabajo.
Si en el proyecto existe slo un grupo de trabajo bajo la direccin del jefe de
proyecto, entonces los procesos CS1-MP1 que tratan sobre el trabajo que el
jefe de proyecto pide que se haga, simplemente se centrarn en al acuerdo
entre el jefe de proyecto y un miembro individual del equipo de trabajo.
El realizar estos procesos formal o informalmente depende del criterio del jefe
de proyecto y de si se quiere guardar registro sobre el rendimiento del
trabajador para posteriores evaluaciones.
MP2 Ejecutar un paquete de trabajo.
Cuando el proyecto es lo suficientemente pequeo como para que no existan
jefes de equipo, el jefe de proyecto llevar a cabo este proceso.
MP3 Entregar un paquete de trabajo.
Este proceso suele ser muy sencillo e informal, simplemente refleja la entrega
del trabajo realizado a quien lo pidi y el aviso al jefe de proyecto de que el
trabajo est hecho.
Si el miembro del equipo de trabajo quiere que quede constancia del trabajo
realizado para una posterior evaluacin de rendimiento, debe pedir al jefe de
proyecto que refleje el trabajo en su informe y que quede por escrito. El
trabajador debera obtener una copia de la evaluacin

Gestionar los lmites de una etapa (SB)

SB1 Planificar una etapa.
Si es un proyecto pequeo, cuyo plan de proyecto es suficientemente completo
para contener todos los detalles necesarios, este proceso no ser necesario.
SB2 Actualizar el plan de proyecto.
Para un proyecto pequeo, todos los detalles de las actividades pueden estar
incluidos en el plan de proyecto, sin planes de etapa separados. Aun as, el plan
56

de proyecto debe ser actualizado con la informacin que se describe en este

proceso.
SB3 Actualizar el caso de negocio del proyecto.
Aunque sea un proyecto pequeo, no se debe asumir que el caso de negocio
es poco importante.
SB4 Actualizar el registro de riesgos.
La evaluacin y gestin constante de riesgos son muy importantes para
cualquier tipo de proyecto, no se puede pasar por alto esta necesidad aunque
sea un proyecto pequeo.
SB5 Informar del fin de etapa.
Si la junta de proyecto est de acuerdo, este informe puede ser simplemente
verbal.
SB6 Producir un plan de excepcin.
Puede existir la tentacin de no volver a generar el plan, y simplemente recordar
los cambios acordados. Es importante, sin embargo, avisar a la junta de
proyecto sobre cualquier desviacin potencial de los mrgenes de tolerancia,
tener un registro de que se han realizado cambios en el plan de etapa para
ajustarse a los cambios y que la junta de proyecto aprob los nuevos objetivos.

Cerrar un proyecto (CP)

CP1 Poner fin al encargo del proyecto
En caso de un proyecto pequeo, la notificacin de la liberacin de los recursos
puede ser muy informal, en algunas situaciones ni siquiera se requiere.
CP2 Identificar acciones posteriores
Puede que no exista ningn requisito por parte del usuario senior para una
revisin post-proyecto.
CP3 Revisin de la evaluacin del proyecto
Es posible que la junta de proyecto no requiera un informe de fin de proyecto
demasiado extenso.

57

Planificacin (PL)
PL1 Disear un plan.
Para un proyecto realmente pequeo es posible que no se necesite una
herramienta de planificacin, aunque se debe considerar muy bien todo lo
establecido en este proceso antes de tomar la decisin de planificar el proyecto
sin ayuda de herramientas.
PL2 Definir y analizar productos.
A veces es tentador pensar que el uso de la planificacin basada en productos
no es necesario, pero la experiencia dicta que es muy fcil olvidar productos o
hacer cosas en un orden equivocado.
Este proceso toma poco tiempo de trabajo y siempre es beneficioso, sea el
proyecto del tamao que sea.
PL3 Identificar actividades y dependencias.
Para un plan pequeo, no es necesario seguir todos los pasos establecidos
para este proceso. Para realizar la estimacin y el control, puede ser suficiente
con el proceso anterior.
PL4 Estimar.
No se debe dar ninguna estimacin del proyecto antes de haber realizado los
pasos que propone este proceso. La estimacin es un compromiso del jefe de
proyecto con la junta y debe cumplirla.
Si no se realizan las estimaciones, por pequeo que sea el proyecto, pueden
olvidarse actividades, verificaciones de cosas que se asumen y cualquier idea
que se tenga en mente. Este proceso ayuda a poner estas cosas por escrito y
concentrarse en dar las estimaciones basadas en toda la informacin
correctamente recolectada.
PL5 Programar.
Si el proyecto es pequeo, es posible que no se necesite una herramienta para
la planificacin, simplemente debe recordarse aadir medidas de tiempo y
esfuerzo a cualquier producto de gestin.
PL6 Anlisis de riesgos.
Este proceso lo llevar a cabo el jefe de proyecto en el caso de que el proyecto
sea lo suficientemente pequeo como para que no haya equipos de trabajo.
58

PL7 Completar el plan.

Aunque no se tenga que hacer pblico el plan, las cosas que se asumen para
el proyecto deben estar adecuadamente documentadas.

4.2 Componentes de PRINCE2 aplicados a un proyecto de pequeo tamao

Caso de negocio
No se debe ignorar que debe existir una justificacin para cada proyecto. Los
proyectos pequeos que se emprenden sin justificacin de negocio pueden
generar prdidas tan grandes como las que generara un proyecto de gran
tamao.
Una opcin posible es llevar a cabo una evaluacin corta e informal del caso de
negocio, pero aun as, el ejecutivo de la empresa debe tener total certeza de que
existe un caso de negocio.

Organizacin del proyecto

En casos en que el proyecto es pequeo, diferentes roles se pueden combinar
y recaen en una sola persona. El ejecutivo puede ser usuario senior, a la vez
que miembro de la junta de proyecto y responsable de monitorizacin y
rendimiento del mismo.
Seguramente no haya necesidad de jefes de equipo, al poder encargarse de ello
el jefe de proyecto. Tampoco se necesitar asistencia de proyecto, ya que el jefe
de proyecto puede tomar esa responsabilidad a su cargo.
Es muy importante tener en cuenta que, aunque el proyecto sea muy pequeo,
ninguna de las responsabilidades de los roles puede ser desechada, la solucin
es asignarla a otro rol para que se haga cargo de ella.

Planes
En este caso, se deben incluir detalles suficientes en el plan de proyecto que
permitan monitorizar y controlar el proyecto entero. Como vimos, en caso de que
esto sea posible, no hace falta otro tipo de plan.

59

Simplemente hay que tener en cuenta que debe encontrarse el suficiente detalle
en la creacin de los productos como para la gestin del da a da del proyecto,
de otra manera no se podr tener suficiente informacin para monitorizar el
progreso.
Hay que tener en cuenta siempre esta necesidad de detalle, a la vez que el
deseo de la junta de proyecto de poder observar el proyecto enteramente en una
pgina.

Control
Etapas
Incluso en un proyecto tan pequeo como para tener una junta de proyecto
compuesta por una sola persona es sensato realizar una etapa de iniciacin.
Resulta beneficioso para el jefe de proyecto documentar los objetivos y el
alcance inicialmente acordado y los trabajadores asignados a cada tarea, sobre
todo en el caso de que posteriormente haya desacuerdos y cambios, ya que
puede referirse a la documentacin y el contrato inicialmente firmado como
respaldo.
Tolerancia
En este caso, probablemente no existan jefes de equipo y el jefe de proyecto
desee permitir pequeos mrgenes de tolerancia para un paquete de trabajo.
Existe el problema de decir a un trabajador individual que tiene cierto margen de
tolerancia para lograr el resultado deseado. Por esta razn, algunos jefes de
proyecto prefieren establecer los mrgenes de tolerancia pero no comentarlos
con los trabajadores.
Gestin del control
Control de la gestin corporativa: probablemente un proyecto de pequeo
tamao no interesar a la gestin de la compaa, el ejecutivo asumir el rol en
este caso.
Control de la junta de proyecto: muchos de los procedimientos de control
establecidos por este componente de PRINCE2 pueden realizarse
informalmente, pero la junta de proyecto debe siempre considerar la
documentacin de sus decisiones que ser guardada en caso de necesitarla
posteriormente.
60

Control del jefe de proyecto: muchos de los controles especificados pueden

hacerse informalmente. Puede que no existan equipos de trabajo, o simplemente
haya uno dirigido por el jefe de proyecto personalmente, esta situacin simplifica
los informes de puntos de control, que el jefe de proyecto verificar con el equipo
de trabajo y escribir l mismo.
Control del jefe de equipo: si existe un solo equipo de trabajo, esta seccin de
control se unir a la del jefe de proyecto.

Calidad
No debemos dejarnos engaar por el tamao del proyecto y por la relativa
facilidad con la que parece que se puede verificar la calidad. Es absolutamente
necesario atenerse a todos los pasos descritos en el procedimiento para evitar
problemas.

Riesgos
Los riesgos, an en un proyecto pequeo, son un factor muy importante para el
proyecto y por tanto hay que seguir igualmente los procedimientos establecidos
para analizarlos y actuar en consecuencia.

Control de cambios
En un proyecto de pequeo tamao el control de cambios seguir siendo igual
de importante que en un proyecto grande. Por tanto se seguirn los pasos
establecidos en el procedimiento.

Gestin de la configuracin
La gestin de la configuracin puede ser llevada a cabo por los miembros del
equipo, el trabajo de Responsable de la configuracin puede formar parte de las
tareas semanales de un miembro del equipo de trabajo cuya principal funcin
sea otra, ya que no le supondr un gran esfuerzo.

61

4.3 Componentes de PRINCE2 aplicados a un proyecto de gran tamao

Caso de negocio
El caso de negocio requiere suficiente tiempo para prepararse; debera existir
previamente, al menos, un esquema de caso de negocio en la peticin de
proyecto y un estudio de viabilidad que contenga tambin elementos a incluir en
el caso de negocio.

Organizacin del proyecto

Cuanto ms grande sea el proyecto, mayor probabilidad existir de que se
necesite una persona para desempear cada rol, incluso es posible que roles
como el de usuario senior sean compartidos entre varias personas, para
proporcionar una perspectiva ms amplia sobre las necesidades del usuario.
Respecto al ejecutivo, normalmente ser slo una persona, ya que es el
encargado de tomar las decisiones clave del proyecto.
En cuanto a los equipos de trabajo, es probable que se realicen
subcontrataciones para desarrollar algunos de los productos del proyecto, por
esta razn, ser necesaria la coordinacin de los jefes de equipo, que pueden
trabajar en reas geogrficas diferentes o en reas de conocimiento diversas.

Planes
En este tipo de proyectos, existe la necesidad clara de utilizar un paquete
software de herramientas de planificacin y control.
Muchos jefes de proyecto intentan hacerse cargo ellos mismos de la creacin y
el mantenimiento de los planes; sin embargo, los trabajadores con el rol de
asistencia de proyecto pueden ser de gran ayuda en estos casos, ya que tendrn
el conocimiento necesario sobre las herramientas y las tcnicas y de esta
manera evitarn la sobrecarga de trabajo al jefe de proyecto.

62

Control
Etapas
La obligacin de la limitacin por etapas de las autorizaciones es especialmente
importante en los proyectos de gran tamao con un entorno continuamente
cambiante, en los cuales se hace prcticamente imposible desarrollar un plan
para el proyecto completo.
Tolerancia
Es muy importante establecer los mrgenes de tolerancia en todos los niveles
descritos en la metodologa. El jefe de proyecto debe considerar
cuidadosamente cualquier margen de tolerancia en el mbito y la calidad que se
haya establecido.
Es muy importante acordar al principio la prioridad de los distintos elementos del
producto para que se pueda establecer una secuencia lgica en el desarrollo.
Gestin del control
Control de la gestin corporativa: los informes de control deben ser
documentados y el jefe de proyecto debe tener copia de ellos.
Control de la junta de proyecto: todos los procedimientos de control debern ser
utilizados y documentados correctamente.
Control del jefe de proyecto: todos los tems y procedimientos deben ser
utilizados. Su documentacin y archivo se considerar parte de la gua de
auditora del proyecto.
Control del jefe de equipo: el jefe de equipo puede estar trabajando para una
gestin diferente de la del jefe de proyecto, esto significa unos objetivos
diferentes y un caso de negocio distinto. Para evitar cualquier problema que
pueda surgir, el jefe de equipo debe atenerse a las guas que le proporciona el
proceso MP.

Calidad
En un proyecto de gran tamao es difcil que el jefe de proyecto pueda verificar
el trabajo de todos los empleados. Debe hacer uso de los trabajadores que z de
cambios

63

En un proyecto de gran tamao pueden realizarse muchas peticiones de cambio,

en este caso es posible que la junta de proyecto no tenga tiempo para
considerarlos todos. Si se llega a esta situacin, puede delegar la tarea en la
autoridad de cambios, un grupo de personas que representen a la junta de
proyecto, especialmente por el lado del usuario.
Para que la autoridad de cambios pueda operar correctamente, la junta de
proyecto le asignar un presupuesto de cambios y pondr algunas restricciones.

Gestin de la configuracin
El rol de responsable de la configuracin debe ser parte de la oficina de
monitorizacin y rendimiento del proyecto, normalmente se requerir la ayuda
de una herramienta software para ello.
Si se prev que existirn muchos cambios a lo largo del proceso, se puede
considerar delegar las tareas de revisin a la autoridad de cambios, con su
presupuesto independiente. Si la junta de proyecto est muy atareada, se
asignar este rol de autoridad de cambios a los miembros de la asistencia del
proyecto.

CONLUSIONES

Despus del estudio realizado, encontramos que PRINCE2 es una metodologa de

gestin de proyectos muy verstil y completa. Se ajusta a cualquier tipo de proyecto,
sin necesidad de ser un proyecto software, con requisitos de tamao muy variables.
Tiene la gran ventaja de que es una metodologa que puede aplicarse parcialmente,
de forma que puede introducirse paulatinamente en una organizacin, o incluso
pueden tomarse algunas de sus prcticas y aplicar otra metodologa para la gestin
del resto del proyecto.

64

PRINCE2 puede resultar de utilidad para cualquier Jefe de proyecto, permitiendo la

seleccin de aquellas ideas o tcnicas que parezcan ms idneas para la tipologa
de trabajo que este desempeando. No obstante, cabe destacar que PMBOK es
conceptualmente ms completo que PRINCE2 y que por tanto, este segundo debe
ser tratado como un complemento al primero.
Por ltimo resaltar que el trabajo realizado en el proyecto ha sido muy gratificante
debido a la cantidad de informacin disponible y las diversas investigaciones en
materia de metodologas de gestin de proyectos y combinacin de metodologas
diversas con PRINCE2.

Bibliografa

Bhm, A. (2009). Application of PRINCE2 and the Impact on Project Management.

Hoffmann, J. (2009). PRINCE2 + giles Vorgehen = Erfolg.
ILX Group. (n.d.). PRINCE2 Exams. From http://www.prince2.com/prince2exams.asp
ILX Group. (2010). PRINCE2 Webinar.

65