Dirección

de proyectos
Objetivos

Proyectos, Programas y Portfolios y su Alineación

Estratégica

En esta asignatura se profundizará en los conceptos de Proyecto,

Programa y Portfolio, así como en los enfoques de Gestión de
Programa y Portfolio, las diferencias existentes en la Gestión de estos
tres tipos de iniciativas Empresariales propias de Organizaciones
“proyetizadas” o “multiProyecto”, las distintas tipologías de
Proyectos que se dan en el ámbito corporativo y la obtención de
“beneficios” (“benefits realization”) para la Organización.

03
ÍNDICE
1. Proyectos, Programas y Portfolios y su
Alineación Estratégica
1.1. Introducción a la Gestión del Portfolio,
Programas y Proyectos
1.2. La Gestión del Programa
1.3. La Gestión del Portfolio
1.4. Diferencias entre Portfolios, Programas
y Proyectos. Ciclo de vida.
1.4.1. ¿Un Proyecto o muchos Proyectos?
1.4.2. ¿”Full time” o “Part-time?
1.4.3. Impredecible o bien conocido
1.4.4. Demanda
1.4.5. Alcance
1.4.6. Medida de éxito
1.5. Definición consensuada de Gestión de
ProgramaGestión de Portafolios

2. Otras definiciones de Gestión de

ProgramaValor para el negocio.
2.1. La Organización multiProyecto
2.2. El MegaProyecto

05
 2.3. Muchos Proyectos para un mismo
Cliente
2.4. Compañías orientadas a Gestión de
programas
2.5. Conclusiones
2.6. Tipos de Proyectos
2.6.1. Proyectos Internos y Proyectos
Externos
2.6.2. Proyectos Materiales y Proyectos No
Materiales
2.6.3. “Corredores”, “Repetidores” y
“Extraños”
2.7. Beneficios

3. Órganos de gobierno estratégico de

proyectos (P.M.O)
3.1. Información
3.2. Definición de Oficina de gestión de proyectos
3.3. Implementación: Nivel Programa y Nivel
Portfolio.
3.3.1. Nivel Programa
3.3.2. Nivel Portfolio
3.4. El Papel de la P.MO.
3.4.1. O.G.P. Nivel 0 (“Servicios Básicos”)
3.4.2. O.G.P. Nivel 1 (“Servicios Adicionales”)
3.4.3. O.G.P. Nivel 2 (“Servicios Consultivos
y de Asesoramiento)
3.4.4. O.G.P. Nivel 3 (“Estrategia y
Gobernanza”)
3.4.5. Conclusiones
3.5. El tamaño importa
3.6. Grado de madurez de P.M.O.
3.7. El éxito de una P.M.O.
3.8. Conclusiones

07
Dirección de 1. Proyectos, Programas y Portfolios y
proyectos su Alineación Estratégica
1.1. Introducción a la Gestión de Portfolio,
Programas y Proyectos
Es extremadamente complicado diferenciar entre
1. Proyectos, Proyectos y Programas.
Programas y
Para empezar, es inclusive difícil encontrar una
Portfolios y definición satisfactoria de Proyecto. El concepto
su Alineación de Proyecto tiene una clara impronta humana,
Estratégica y puede tener muy diversos significados para
distintas personas. Una definición sencilla sería:
“un grupo de personas trabajando de forma
coordinada para realizar algo”.

¿Es posible pensar en algún Proyecto que no

contenga Proyectos de menor escala (“sub-
Proyectos”) y que, a su vez, no sea parte de un
Proyecto de mayor envergadura y complejidad?

En definitiva, los Proyectos y Programas forman

parte de un espectro: algunas iniciativas son
claramente Proyectos y otras son, sin duda
alguna, Programas; pero un número significativo
puede tener la doble consideración de Proyecto y
Programa.

Por lo tanto, en el ámbito profesional de la Gestión

de Proyectos dentro de la Empresa, los términos
Project, Programme y Portfolio Management tienen
una amplia variedad de significados, apreciándose
en la Comunidad Profesional Internacional una
clara falta de consenso (de forma idéntica al caso
particular de la P.M.O., como se verá en el último
bloque de la asignatura).

Aun así, la mayor parte de los profesionales

están de acuerdo en que la Gestión de Programa
supone la gestión de varios Proyectos. En la
práctica, esta definición incluye a la mayoría de las
Organizaciones que gestionan diversos Proyectos,
tratándose, por tanto, de la mayor parte de las
Empresas de un tamaño significativo.

Una gran mayoría de especialistas de gestión

acordará que la Gestión del Programa requiere dar
un paso atrás, aplicar un “zoom lejano”, panorámico,
 desde el problema puntual de un Proyecto hasta la visión de conjunto del Programa que facilite
el éxito en su gestión.

Muchos, pero no todo el conjunto de especialistas en Gestión de Programa, estarán de acuerdo

en que la Gestión de Programa versa más sobre la Gestión del Cambio (Change Management)
que sobre la entrega de Productos (Products Delivery). Desde este enfoque de la Gestión de
Programa, los Proyectos dan como resultados “Productos”, mientras que el Programa aporta
como resultado un “Outcome”, es decir, una Cambio para la Organización.

Sin duda que la mayoría de los profesionales mantendrá que la Gestión del Portfolio hace
referencia a todas las iniciativas (Proyectos y Programas) dentro de la Organización.

De cualquier forma, es importante saber que hay iniciativas intermedias que podrían tener
consideración tanto de Proyecto como de Programa o Portfolio.

1.2. La Gestión del Programa

Tómese en consideración, inicialmente, el concepto de Programa de Cambio (Change
Programme). Una definición válida para este concepto es:

“La Gestión Coordinada de un grupo de Proyectos diseñados para modificar o cambiar la forma
en que una Organización opera”

Desde el punto de vista de esta definición, la Organización diseña y pone en marcha una serie
de iniciativas denominadas Proyectos con la misión de promover un Cambio Organizacional.

Existen muy diversos objetivos de cambio:

• Incrementar las ventas o facturación.

• Reducir los costes operativos o de explotación del negocio.

• Alcanzar mejores niveles de servicio.

• Mejorar los niveles de calidad.

Aun así, debe tenerse especial cuidado con la palabra “Cambio” en relación con la Gestión
del Programa, ya que ésta no persigue el cambio per-sécomo tal, sino que, busca la “mejora”.
Es posible que el Cambio Organizativo introduzca un empeoramiento de los procesos de la
compañía, por lo que, el objetivo es la promoción de un cambio que introduzcan mejoras.

Los Programas, a través de su gestión coordinada e integrada, tienen como finalidad materializar
la Estrategia de la Organización, de forma que una compañía podría poner en marcha distintos
Programas atendiendo, cada uno de ellos, objetivos de negocio (estratégicos) de muy distinta
índole, por ejemplo: “elevar los niveles de satisfacción de Cliente”, “reducir desperdicios o
pérdidas” o “desarrollar nuevos mercados”.

Siempre, el nivel de éxito en la Gestión del Programa se medirá a través de los beneficios
conseguidos (materialización o consecución de objetivos de negocio, precisamente aquellos por
los que se constituyeron los Programas). Se habla entonces de consecución de beneficios. Los

09
cambios producidos, con sus objetivos materializados (incremento de ventas, adelgazamiento
de la estructura de costes, etc.), son disfrutados por la Organización hasta mucho tiempo
después de que los respectivos Programas (de Cambio Organizacional) hayan sido terminados
o cerrados (en su gestión).

Por ejemplo, un objetivo de Cambio interesante que podría plantearse una Organización sería
una mejor entrega de Proyectos (eficacia y eficiencia), para lo que constituye un Programa con
dicho objetivo –de negocio- estratégico para la compañía.

Hasta aquí se ha unido la Gestión del Programa con la Gestión del Cambio, de forma que
se entiende el Programa como un Programa de Cambio que persigue la introducción de una
o varias mejoras, es decir, la consecución de un objetivo (o beneficio) o varios objetivos (o
beneficios) para la Organización.

Pero, la diversidad de definiciones de Gestión del Programa, como ya se ha comentado en la

introducción, es amplia, encontrándose otras versiones, que incorporan matices y diferencias
importantes. Así, se comprueba lo extendido de la perspectiva de que la Gestión del Programa
incluye la Gestión de Proyectos, y algo más.

No cabe duda de que la Gestión del Programa supone un área limítrofe entre los Equipos
de Gestión de Proyectos (Project Management) y el Equipo de Dirección Estratégica de la
Organización (el nivel ejecutivo de la compañía: Senior Management o C-Level).

En esta área limítrofe es donde cada Proyecto es definido (marco, alcance, entregables,
restricciones, limitaciones, suposiciones, etc.) persiguiendo el “encaje estratégico” (“strategic
allignment”) de todos los Proyectos con los objetivos estratégicos del Programa, así como su
planificación integrada (cohesionada, con un hilo conductor único en su gestión, lo que hablaría
de una gestión coherente del Programa).

De esta forma,

• Definición de los Proyectos que componen el Programa.

• Autorización a Project Managers (Gerentes de Proyecto) específicos para la gestión de los

Proyectos que conforman el Programa.

• Supervisión y control (del cambio) de los Proyectos en curso.

• Promoción de un ambiente de trabajo (gestión) propicio para el éxito en la gestión de todos

los Proyectos del Programa.

Así, desde este enfoque de Gestión del Programa, es fácil entender que nunca un Programme
Manager hace “micro- management” (“micro-gestión” o “gestión del detalle”), sino que, se
establece un enfoque de “alto nivel”, de visión a largo plazo; evitando centrarse en el detalle de
la gestión de los Proyectos que integran el Programa.

Es importante destacar la exigencia, trasladada al Director del Programa desde el conjunto

de la Organización, de saber responder, cuando se está en plena Gestión del Programa, ante
cambios estratégicos o del entorno que afecten al mismo, de forma que el Gerente de Programa
sepa identificar aquellos Proyectos en curso no alineados con dichos cambios, siendo capaz
de proceder a su eliminación, así como, lanzar nuevos Proyectos que sí encajan con dichos
cambios.
 En conclusión, el término de Gestión del Programa se emplea para cubrir la gestión de cualquier
grupo de Proyectos relacionados entre sí. Inclusive un contratista externo que afronta el
desarrollo de diferentes Proyectos para un mismo o diferentes Clientes empleará, también, el
término Gestión del Programa para el manejo coordinado de todos ellos.

Dichos Proyectos tienen por finalidad la consecución de ciertos beneficios (objetivos

de negocio) para la Organización Cliente y generar beneficio, en paralelo, para el propio
Contratista o compañía proveedora externa. No cabe duda entonces, de que dichos Proyectos
están conectados de alguna forma, a través del uso compartido de recursos de la Organización
Contratista, de solapes en el tiempo a la hora de ejecutar distintas actividades o tareas, de
tecnología compartida, etc.

Sintetizando lo indicado en el punto “Un programa es un grupo de proyectos relacionados,

programas subsidiarios y actividades de programas, cuya gestión se realiza de manera
coordinada para obtener beneficios que no se obtendrían si se gestionaran de forma individual.”

Según el PMBok 6ª edición.

1.3. La Gestión del Portafolio (Portfolio Management)

Fundamentalmente en el caso de Organizaciones de tamaño o escala significativa, los
Proyectos y los Programas son gestionados de forma simultánea. Este tipo de compañías, si
quieren ser exitosas en la gestión de estas iniciativas Empresariales (Programas y Proyectos)
deben tener experiencia en la gestión integral de la carga de trabajo (“workload”) y perseguir
una mejora continua de sus Operaciones a través de dichas iniciativas de negocio.

Es habitual que estas Organizaciones encajen una capa de nivel Portfolio Management entre el
nivel Sénior (Dirección de la Compañía) y la Dirección de Programas (Programme Managers) y
Proyectos (Project Managers).

En el siguiente gráfico se expone la estructura de una Organización por “capas” de gestión

de Portfolio, Programa y Proyectos. Obsérvese la unidad de Proyectos al nivel de Programa.
Una Organización puede así configurar sus estructura cuando los Proyectos que maneja dicha
unidad –ubicada a nivel Programa- son de tal relevancia o importancia estratégica para la
compañía que conviene una supervisión directa del Equipo de Gestión del Portfolio ubicado
justo por encima.

11
La Gestión del Portfolio puede ser entendida desde una doble perspectiva:

1. Como una “capa de gestión” (“management layer”),, donde se inserta el equipo responsable
de todas las iniciativas, Programas y Proyectos de la Organización.

2. Como un “proceso”, el proceso de identificación, selección, definición y priorización de

Programas y Proyectos dentro de la Organización.

Por lo tanto, el equipo responsable de la Gestión del Portfolio busca entender el posicionamiento
estratégico de la compañía para así diseñar el conjunto de Programas y Proyectos más
adecuado a la Estrategia de la Organización. Desde esa óptica, el conjunto de Programas y
Proyectos más adecuado será aquel que facilite el óptimo equilibrio entre tres factores:

Factores de Equilibrio en la Gestión del Portfolio

La Gestión del Portfolio exige la evaluación previa de alternativas a la toma de decisiones

en torno a la cartera de Programas y Proyectos a conformar en línea con la Estrategia de la
Organización, lo que conlleva, con frecuencia, una intensa actividad inicial de investigación y
recopilación de información. Por lo tanto, la Gestión del Portfolio está lejos de ser una única
actividad. Se trata de una actividad de gestión continua que requiere presentar o exponer ante
el la dirección de la compañía) con regularidad (generalmente cada tres meses). En dichas
presentaciones el Equipo de Gestión del Portfolio llevará a cabo las siguientes acciones:

• Presentar la información actualizada del uso de recursos.

• Destacar los resultados derivados de las investigaciones y análisis realizados durante los
últimos tres meses.

• Resumir el avance o progreso del Portfolio, enfocando la atención en el grado de

cumplimiento de los objetivos estratégicos, así como la materialización, o no, de los
beneficios esperados (“benefits realization”)..

• Recomendar nuevos Programas y Proyectos, así como cambios a los Programas y Proyectos
ya existentes en curso (incluso la cancelación de algunos de ellos).

• Mostrar su apoyo, o no, a las propuestas procedentes de la misma Dirección de la Compañía

13
Ejemplo práctico de gestión del portfolio

Un proveedor de materiales del hogar en edificación residencial recientemente ha tomado la

decisión (su Comité Ejecutivo –Committee Board, Senior Management-) estratégica de crecer, de
expandir su negocio, con el objetivo estratégico establecido de avanzar desde la posición 8ª hasta
la 4ª dentro del ranking nacional de distribuidores o suministradores en edificación.

Para ello, el Comité que dirige la Gestión del Portfolio (Portfolio Management Board) ha decidido que
la expansión se realice mediante la creación de nuevos servicios D.I.Y. (“Do It Yourself”) destinados
a las construcciones/edificaciones ya existentes, una necesidad no satisfecha por la industria, y
que permitiría ampliar el target Cliente de la compañía, por lo tanto, con una repercusión directa
en ventas (incremento facturación y margen de beneficio).

Tras un estudio previo de investigación donde se recopilan multitud de datos, el Comité de Gestión
del Portfolio decide establecer tres (3) programas (los tres componen la cartera o Portfolio de
Proyectos de la compañía vinculada con su Estrategia de desarrollo de negocio):

1. Programa de Expansión de Tiendas (puntos de venta).

El objetivo del Programa es incrementar el número de tiendas de 40 a 70, a través de la apertura

de nuevas tiendas en las principales conurbaciones urbanas del país.

2. Programa de Servicios del Hogar.

Este Programa tiene por finalidad lanzar un amplio rango de servicios dirigidos a los propietarios,
incluyendo cocinas y baños ajustados a las necesidades específicas de los clientes. Esto conllevará
la ampliación del espacio físico de las tiendas existentes para integrar los expositores de baño y de
cocina, así como el partnership con contratistas especializados en el montaje de cocinas y baños
en cada una de las regiones, incluyendo servicios adicionales de garantía de montaje o instalación
y revisiones de seguridad; creando así un nuevo departamento de Diseño de Baño y Cocina dentro
de la compañía.

3. Programa de Producción o Manufactura.

Este Programa tiene por objetivo la creación de una nueva planta de producción o manufactura para
la fabricación de ciertas líneas de producto que venían adquiriéndose con regularidad (“buy in”). El
alcance exacto de la nueva planta incluye: edificio, línea de producción, área de almacenamiento,
control de stock y nuevo sistema de distribución.

En paralelo se esperan otras iniciativas vinculadas con la expansión, en este caso Proyectos
relativamente pequeños dentro de los departamentos de:

• Sistemas.

• Recursos Humanos.

• Contabilidad.
1.4. Diferencias entre Portfolios, Programas y Proyectos. Ciclo de vida.
“Los Proyectos producen/entregan salidas (outputs), los Programas producen/entregan
resultados (outcomes)”.

Esta frase es ciertamente elocuente a la hora de establecer la diferencia entre Proyecto y

Programa. Cabe entender que el Programa produce resultados, consecuencias o logros (de
negocio, es decir, la obtención de beneficios, en definitiva, éxitos.

Esto es cierto respecto de la gran mayoría de Organizaciones que manejan Programas

(constituidos por Proyectos relacionados entre sí) para la mejora de sus procesos de negocio.
Dichas Organizaciones procuran que todo Project Manager o Gerente de Proyecto:

• Tenga en mente una clara definición del producto, entregable/es o ouputs del Proyecto, y,

• comprenda cómo “su” Proyecto se relaciona con el resto de Proyectos que componen el
Programa.

La clave respecto de la gestión integral del Programa está en que su equipo gestor facilite la
agrupación de todos los productos, entregables o outputs de los Proyectos que lo componen,
con la finalidad de crear “capacidad”.

Esta “capacidad” es entregada por el Equipo de Gestión del Programa al Equipo de Dirección
de la Organización para la generación de resultados de negocio, en definitiva, beneficios.

En esencia, el Programa está constituido por una serie de Proyectos relacionados entre sí
(dependencias), cada uno de ellos gestionado por un Directores de proyectos especialista en
su área de trabajo respectiva.

El Equipo de Gerencia de Programa se encargará de definir los Proyectos (estudiar su

alcance, viabilidad; constituirlos en definitiva) y delegar su gestión individualizada al Project
Manager competente, integrado éste en un departamento o área específica de la Estructura
Organizativa de la Compañía.

Sólo cuando todos los Proyectos que integran el Programa se han finalizado o completado
(entregado los outputs, razón por la que se crearon dichos Proyectos), las “salidas” o
“outputs” de los Proyectos son integrados por el Equipo de Gestión del Programa para crear
la “capacidad” objetivo de dicho equipo, una “capacidad” que, como se ha indicado ya, se
pone a disposición de la Dirección de Negocio de la Organización. Sólo en este momento
puede hablarse de “outcomes”, es decir, consecución de resultados de negocio u obtención de
beneficios.

Se presenta a continuación un gráfico demostrativo de “La Curva de Valor” (“The Value Path”)
que permite entender el escalado progresivo en la generación de valor para la Organización
desde el Proyecto, pasando por el Programa hasta la obtención de “beneficios” de negocio.

15
El término “outcome” hace referencia a la forma en que el Programa contribuye al conjunto
de la Organización, por ello, suele expresarse en forma de términos cualitativos. Pero, el
resultado del Programa, también debe medirse en términos cuantitativos; unas medidas que
deben ser entendidas como beneficios (cuantificables) de Programa

En conclusión, los “beneficios de negocio” (el punto más alto de la “curva de valor” presentada)
son conseguidos para el conjunto de la Organización mediante la asociación de las diferentes
“capacidades” creadas por los distintos Programas en curso de la compañía.
Se está ya en disposición de entender las diferencias y claros matices existentes entre los
conceptos de “Gestión del Portafolio” (“Portfolio Management”), “Gestión del Programa”
(“Programme Management”) y “Gestión del Proyecto” (“Project Management”). Se presentan
a continuación, de forma sintética, en la siguiente tabla tal y como realiza el PMBOk 6ª Edició,
en lo rferente a Direccion de técnica de proyectos:

17
Todo proyecto presenta un ciclo de vida en el cual se pueden identificar las diferentes fases
por las que atraviesa el proyecto, durante su ejecución, en función del tipo de proyecto puede
presenta diferentes tipos de ciclos de vida teniendo en cuenta los factores->Alcance->tiempo-
>coste, identificando los siguientes:

1. Ciclo de vida predictivo (asociado habitualmente a proyecto del tipo ingeniería y

construcción), en el que el alcance, tiempo y coste del proyecto se identifican al inicio del
mismo, estando perfectamente acotados y definidos.

2. Ciclo de Vida iterativo en este tipo de proyecto en un momento temprano se define el

alcance del mismo pero no es así con el plazo y el coste, los cuales sufren modificaciones
según evoluciona el proyecto.

3. Ciclo de vida Incremental el alcance y el costo sufren modificaciones a lo largo de la vida

del proyecto pudiendo conocer en el inicio del mismo el tiempo estimado del mismo.

4. Ciclo de vida adaptativo, este tip de proyectos son los que en la actualidad son considerados
proyectos ágiles, en los cuales el alcance se define con cada una de las iteraciones que
sufre el proyecto siendo lo suficientemente flexible para afrontar los cambios de todos y
cada uno de los factores del proyecto.

Los proyectos deben tener identificadas las diferentes fases o subproyectos para identificar
los trabajos que se están realizando en ese momento:

• Desarrollo conceptual,
• Estudio de viabilidad,
• Requisitos del cliente,
• Desarrollo de soluciones,
• Diseño,
• Prototipo,
• Construcción,
• Prueba,
• Transición,
• Puesta en marcha,
• Revisión de hitos, y
• Lecciones aprendidas.

Cada una de dichas fases (también denominadas “sub-Proyectos”) se gestiona de forma

independiente aplicando los cinco grupos de procesos (Iniciación, Planificación, Ejecución,
Supervisión y Control y Cierre). Las habituales limitaciones o restricciones de tipo temporal
(plazos ajustados) que se dan en dichos sectores condicionan la concepción del esquema de
desarrollo global del Proyecto conjunto, solapando las fases o sub-Proyectos (“fast-tracking”).

Sin embargo, en su gestión, muchos Programas parecen no acabar nunca, o tener un final
definitivo. Otros tantos Programas son implementados durante un largo período de tiempo y
se “apagan” sin resultados concretos. Todos ellos se mantienen en vida durante el tiempo en el
que el Equipo de Gestión de Programa consigue obtener los beneficios de negocio esperados.
Es crítico resaltar que los Programas, de forma habitual, son como un “organismo vivo” que
llega a sufrir una importante “metamorfosis”, adquiriendo un nuevo perfil o forma, con nuevos
objetivos. En el mercado pueden encontrarse Organizaciones implementando Programas
con una longevidad de hasta 65 años. Los Portfolios, en ocasiones, sólo cesan cuando la
Organización “muere” o termina su actividad Empresarial.

Los Proyectos pueden tener una planificación temporal inicial realizada en forma de esquema
(sketch) o boceto, un “cronograma de alto nivel” con los hitos críticos del mismo (hitos iniciales,
intermedios y finales).

Sin embargo, los Programas cambian con relativa frecuencia, durante su vida útil, sus objetivos
y Estrategia, y, por lo tanto, su escala temporal (cronograma).

Por supuesto, un Portfolio,

compuesto por Proyectos, tanto
“internos” como “externos”, que
entran y salen de la cartera, no
puede programarse, en términos
de tiempo, en un boceto o
esquema, como se podría hacer,
a nivel maestro, con un Proyecto.

Para programar la carga de

trabajo de un Portfolio se
necesitaría todo un mural o
panel en el que mostrar la
programación coordinada de
los Programas y Proyectos que
componen el Portfolio de la
Organización. Nuevos Proyectos
son insertados en la “zona de
cola” (entrada en ejecución),
mientras que los Proyectos
ya finalizados son eliminados
del “dash-board” (“cuadro de
mando”) de control del Portfolio.

En definitiva, no existen
diferencias significativas entre
Programme Managementy
Project Management,
especialmente cuando se trata
de su “planificación”. Aun así, en
la actualidad existen matices o
tendencias en ambos ámbitos
(Gestión del Programa y Gestión
del Proyecto), que son presentados de forma abreviada en la siguiente tabla.

19
1.4.1. ¿Un proyecto o muchos Proyectos?
Ciertos Project Managers tienen la “suerte” (toda una recompensa) de trabajar en la gestión de
un único Proyecto, es decir, la situación opuesta a la multitarea o multiproyecto, tan habitual
en el ámbito Empresarial.

En dicho caso, el Equipo de Gestión del Proyecto focaliza su atención en un sólo Proyecto, una
situación característica de sectores como el de Ingeniería y Construcción, donde la complejidad,
envergadura, alcance y escala de los Proyectos (Infraestructuras, Energía, Instalaciones, etc.)
es tal que requiere una atención total, dedicada, por parte de los Equipos de Gerencia a dichos
Proyectos de Desarrollo.

Una situación “ideal” probablemente “envidiada” por Project Managers que actúan en otras
áreas o sectores, como pueda ser el de las nuevas tecnologías, finanzas/banca, biotecnología,
farmacia, consultoría, etc.

Los Directores de proyectos que lideran la gerencia de Proyectos en industrias “pesadas”, en

las que el objetivo es la entrega de un activo material de peso (infraestructuras del transporte,
urbanas, hidráulicas, energéticas, etc.), centran su actividad gerencial en la terna “tiempo,
presupuesto y recursos”, todo un reto dada la complejidad y magnitud de dichos Proyectos.

Sin embargo, la Gestión del Programa es idéntica a la actuación coordinada de artistas de

circo, en formación circular, todos ellos haciendo malabares con las tres bolas de tiempo,
coste y recursos, y, de vez en cuando, intercambiando bolas entre sí.

Dentro del Programa, cada Proyecto tiene sus restricciones de tiempo, coste y recursos, pero,
no debe perderse de vista el impacto que la gestión de cada uno de dichos Proyectos tiene
sobre la gerencia de los restantes Proyectos relacionados. Se comprende entonces el perfil
estratégico que caracteriza a la Gestión del Programa.

Otra similitud gráfica que permite entender las diferencias entre Gestión de proyecto y Gestión
de programas es comprender la primera gerencia, la de Proyecto, como un mundo plano
bidimensional (2D), en oposición al ámbito tridimensional de la gerencia de Programa (3D).

Los Gerentes de Programa junto con su equipo de gerencia deben constituir y consolidar
Equipos de Gestión de Proyecto para cada Proyecto y supervisar y controlar las interacciones
entre todos los Equipos de Proyecto, los recursos involucrados (recursos compartidos:
“transferencia”/“transversalidad”) y los propios Proyectos.

En un Proyecto único, normalmente el alcance establece un entregable como objetivo del

mismo. Cuando dicho Proyecto finaliza, es decir, cuando se aprueba el entregable y se cierra
su gestión, los integrantes del Equipo de Gerencia se reunirán en torno al Proyecto finalizado
mostrando una clara satisfacción por la consecución del objetivo de Proyecto.

Sin embargo, cuando se habla de la Gestión del Programa, los entregables son múltiples, y, en
paralelo, se contemplan cambios organizativos de difícil definición al inicio de la implementación
del Programa.
1.4.2. ¿”Full-time” o “Part-time”?
En los Proyectos de Ingeniería y Construcción quedan involucrados recursos de distinta
índole (materiales, de Equipos, humanos, de capital) en la línea operativa de cada Proyecto,
pero habitualmente los recursos finales proceden de la “sub-contratación”; por lo tanto,
la contratación (o despido) y el seguimiento y control (productividad) de dichos recursos
individuales queda sujeta a las práctica de la “sub-contratación”, tan característica de dicha
industria o sector.

Ello no implica que en este sector de Ingeniería y Construcción no sea preciso conformar o
constituir, previamente al desarrollo del Proyecto, el Equipo que lo va a gestionar; así como,
identificar y contratar directamente recursos específicos precisos para el desarrollo de tareas
muy concretas o puntuales (sobre todo cuando la “especialización” es requerida). Pero, de
forma progresiva, con el avance del Proyecto, el Gerente del Proyecto (Engineering Project
Manager) interactúa con otras compañías (“sub-Contratistas”) que directamente tratarán con
los recursos individuales requeridos para el Proyecto de Ingeniería y Construcción.

Esta es una forma implícita, casi “furtiva”, por parte del Director de proyecto, de expandir el
Equipo de Gerencia del Proyecto, en cuanto que cada “Contratista” contribuye en parte a la
Gestión del Proyecto.

De esta forma, tal y como ocurre en Ingeniería y Construcción, Director que dirige un único
Proyecto, cuanto menos personal contrate de forma directa, menor será el coste de estructura
de personal asociado a su Proyecto y, además, menor la cantidad de talento que deje escapar
cuando el Proyecto se cierre.

Sin embargo, los recursos en un Programa trabajan de forma “part-time” tanto en cada uno de
los Proyectos que lo componen, como en el propio Programa en su conjunto (un mismo recurso
–persona- estaría trabajando de forma parcial para cada uno de los Programas que componen
el Portfolio, si éste tiene más de un Programa). Bajo este esquema de trabajo, por ejemplo, un
Ingeniero Especialista tendría una disponibilidad limitada para un Proyecto específico, siendo
arrastrado de Proyecto en Proyecto (dentro de un mismo Programa o, inclusive, entre distintos
Programas), sin poder concentrarse o enfocar su atención en ninguno de ellos.

1.4.3. Impredecible o bien conocido

Los Proyectos, cuando son gestionados “uno a uno” (la praxis propia del sector Ingeniería y
Construcción), representan nuevos, inusuales retos a Managers y Planners, para los que idear
la forma de conseguir el éxito del Proyecto supone un auténtico rompecabezas.

Por lo tanto, la naturaleza de los Proyectos así encarados la de la “singularidad” (dos Proyectos
siempre son muy diferentes, y requieren un aprovechamiento de la gestión bien distinto).

Si bien cierta guía u orientación puede obtenerse de experiencias pasadas (Proyectos de

similar naturaleza, parecida complejidad o envergadura, etc.) –“estimación análoga”, “juicio de
expertos”-, el Equipo de Gestión del Proyecto siempre afronta un reto único y singular con el
nuevo Proyecto en curso.

Los especialistas en áreas técnicas de Ingeniería y Construcción (Estructuras, Hidráulica,

Electromecánica, etc.) responden a las primeras preguntas de gran calado que se plantea el
equipo de gerencia (lo hacen a través del “method statement”, el cual define el alcance del
trabajo a realizar en la realización de un componente clave o fase del Proyecto).

21
Habitualmente, los Gerentes de Proyecto en la industria de Ingeniería y Construcción, al inicio
del Proyecto, plantean las grandes cuestiones del Proyecto. La planificación, programación
y control mediante “métodos de trayectoria crítica” (“critical path planning”) juega un papel
clave a la hora de resolver aquellas preguntas iniciales que empiezan por “¿cuándo…?”. Pero,
no sólo los Project Managers se preguntan por el “¿cuándo?” sino también por el “¿cómo?”.

Los “Proyectos componente”, aquellos que integran el Programa, tienden a ser relativamente
sencillos y predecibles en su gestión. De esta forma, cuando se afronta la primera planificación
de un nuevo “Proyecto componente”, se crea el “Plan estándar”, modificando las duraciones
de actividades y tareas en concordancia con la carga de trabajo esperada para dicho Proyecto
en particular. La secuenciación temporal de fases de un “Proyecto componente” será también
idéntica (estándar).

De hecho, el “faseado” o secuenciación de los “Proyectos componente” de un Programa se

suele articular o estructurar en forma de “metodología”.

Cabe decir, por tanto, que la mayor parte de la Gestión de Proyectos se trabaja sobre tres
variables :

(1) Supervisión y control del “Camino Crítico” (“Critical Path”), Punto , momentos o
elementos del proyeto que no vana permitir que este siga el curso previsto , por los que
se debe realizar un control o monitorización mas exhaustivo.

(2) Método de gestión. Este dependerá de la tipología de proyecto.

(3) Gestión del tiempo o planificación Vendra determinada por el equipo y las
necesidades del cliente.

1.4.4. Demanda de Recursos

Otra diferencia significativa entre la Gestión del Proyecto y la Gestión del Programa es la
forma del histograma de recursos (representación gráfica del recurso en forma de barras,
verticales por cada unidad de tiempo).

En el ámbito de gestión de único Proyecto el Equipo de Gestión adquiere los recursos de

personal que precisa para lograr los objetivos del Proyecto (en plazo, dentro de presupuesto
y adherido a especificaciones de calidad). El objetivo clave del Cronograma(integrado en el
Equipo de Gestión) es optimizar al máximo el uso de recursos. Si la ejecución se retrasa sobre la
línea base del Cronograma, la primera alternativa será la contratación de recursos adicionales
(con impacto en coste, en consecuencia).

Sin embargo, en el ámbito de la Gestión del Programa, los niveles de recursos son mucho más
fijos y estáticos. La asignación o reclutamiento de personal nuevo para los departamentos
funcionales vinculados con la Gestión del Programa lleva un tiempo mucho mayor. Además,
deshacerse de ciertos recursos tiene un impacto en coste y plazo directo, no desdeñable. Por
tanto, el Equipo de Gestión del Programa tiene dos objetivos:

1. Mantener ocupados al 100% todos los recursos involucrados en la Gerencia del

Programa, es decir, maximizar la contribución de cada Equipo de Gestión de Proyecto
“componente” al éxito de la Organización.

2. Realizar un seguimiento exhaustivo de la demanda futura de recursos.

Los Project Managers buscan contratar el menor recurso humano compatible con el avance
o progreso requerido para el cumplimiento de los objetivos del Proyecto. La precisión de la
Planificación de Recursos (“Resource Planning”) no es, de forma habitual, suficientemente
buena como para planificar el detalle del recurso individual; considerándose como buena
planificación de recursos aquella que facilita la previsión de recursos para el siguiente mes
de ejecución. Generalmente, el Project Manager puede contratar, de forma puntual, recursos
extra, inicialmente no previstos. En la medida que es compatible con el avance pronosticado
para el Proyecto, los Project Managers de Ingeniería y Construcción procuran contratar el
menor número posible de recursos, minimizando los requerimientos de recursos.

Los Gerentes de Programa cuentan con un “pool” fijo de recursos (humanos). La “fuerza
– humana- de trabajo” puede ser ampliada o reducida vía contratación o suspensión de la
misma, si bien, estos procesos toman su tiempo, no baladí. Por lo tanto, a las personas se les
demanda mucha agilidad cuando se las incorpora a la gestión de los “Proyecto componente”
que integran el Programa. Bajo este enfoque, es fácil planificar la actividad de una persona
(recurso individual) en el marco temporal de una media jornada laboral o, incluso, horas. El
objetivo entonces, para el Programme Manager, consiste en mantener ocupado a todos los
recursos, propiciando la máxima eficiencia del Programa.

Por lo tanto, los Gerentes de Proyectos (Project Managers) abogan por bajos niveles de
utilización de recursos, al contrario que los Gerentes de Programa (Programme Managers), por
lo que, el histograma de recursos del Project Manager es de “baja carga”, y el del Programme
Manager es “suavizado”, sin picos y valles, con el nivel de carga de recurso (“workload”) alto y
constante.

1.4.5. Alcance
Los Gerentes de Proyecto prefieren el establecimiento de objetivos concretos, medibles,
alcanzables, realistas y realizables en término de tiempo( definidos en ingles con las siguiente
siglas S.M.A.R.T.) ; lo cual no implica que la consecución de dichos objetivos sea fácil, al revés,
generalmente, y la práctica profesional y formal del Project Management así lo demuestra, es
difícil alcanzar un nivel alto de éxito en un Proyecto.

Se empleará un ejemplo, bastante gráfico, para entender el papel del Project Manager según
este enfoque.

Supóngase un Proyecto de Desarrollo Inmobiliario de lujo (“luxury real estate”), ya finalizado

y entregado al Cliente de acuerdo a las especificaciones establecidas, y, además, en plazo y
presupuesto (todo un éxito desde el punto de vista de su gestión).

Si el mercado inmobiliario, por distintas circunstancias (por ejemplo la “crisis inmobiliaria”

norteamericana de 2.007/08), sufre una reducción drástica en el precio del metro cuadrado
de suelo edificado (de “obra nueva”), la promoción inmobiliaria no podrá comercializarse en
los términos en los que se había previsto (que demostraban el Proyecto “viable” y “rentable”).

El C.E.O. (“Chief Executive Office”, máximo ejecutivo de una Organización) de la Promotora

Inmobiliaria (el Cliente del Project Manager y su Equipo de Gerencia de Proyecto) se estará
“tirando de los pelos” preguntándose por qué su Proyecto ha tenido la “desgracia” de caer bajo
tal “horrible destino” (las causas podrían encontrarse en una mal análisis del riesgo, entre
otras).

Independientemente de la situación en la que queda el Cliente, con el Proyecto bien entregado

y el posterior descalabro del mercado inmobiliario con impacto directo en su promoción
(todo una “ruina”), el Project Manager “se desentiende” de esta problemática, no esperada,

23
considerando su trabajo de gestión realizado: la promoción inmobiliaria entrega en plazo,
dentro de presupuesto y cumpliendo las especificaciones (Calidad) establecidas.

Los Gerentes de Programa (Programme Managers) deben centrarse en la generación de

“beneficio” para la Organización (“benefits realization”). Por lo tanto, cae bajo su responsabilidad
observar, analizar y escrutinar el entorno de la Organización para asegurarse que los objetivos
(del Programa) todavía tienen sentido en el contexto dinámico, cambiante, de la Compañía; y,
están alineados con su Estrategia.

Ello implica que el Programme Manager puede, y debe, sacar del Programa aquellos Proyectos
que no cumplen con dichas condiciones (condiciones de contorno y encaje estratégico) –en el
momento en que ello sea detectado (tras una conveniente evaluación)-, modificar o reenfocar
aquellos Proyectos que lo requieran, e, introducir nuevos Proyectos.

De esta forma, es fácil comprender que los Gestores de Programa siguen de cerca los “objetivos
corporativos”, siempre sujetos a una continua evaluación, interpretación y cambio.

Los cambios en los objetivos corporativos muchas veces vienen determinados por el propio
entorno externo o por razones internas a la propia compañía, por ejemplo:

• Cambio político, normativo o legal (externo)

• Aparición de nuevas condiciones de carácter medioambiental (externo).

• Cambio en procesos o procedimientos, promovido por el nivel corporativo (interno).

1.4.6. Medida de éxito

El Project Manager del sector de Ingeniería y Construcción - aquel que, entre otros, propicia
una Gerencia de único Proyecto (“single project environment”)-, para tener éxito en su carrera,
debe centrarse en la entrega del producto adecuado cumpliendo el plazo y coste determinados.
En definitiva, su objetivo es la entrega del “output” o “salida” del Proyecto de acuerdo a
especificaciones muy bien detalladas (diseño), ajustado a una Cronograma de Desarrollo,
inicialmente “soñado”, “concebido” o “ideado” (en forma de draft, sketch o boceto) y dentro de
un marco presupuestario ajustado por el Cliente o Usuario final.

El Programme Manager tiene una tarea mucho más compleja por delante. El Programa esta
“rodeado” de una serie de “stakeholders”, actores interesados en el éxito, o no, del mismo,
en su totalidad o parte de él. El Programa estará conformado por un conjunto de Proyectos
“componente” que, si son finalizados de forma exitosa, es decir, entregando los productos
(resultados) por los que se concibieron (dichos productos son empleados por la Organización
en su propio beneficio), una parte de los “stakeholders” se congratularán de ello.

La medida del éxito en el caso de la Gestión del Programa está íntimamente ligada a los
“beneficios” generados, los cuales suelen escaparse al control del Gerente de Programa. Por
lo tanto, el éxito, en el marco de la Gestión del Programa, tiende a ser mucho más subjetivo e
intuitivo que el éxito en Project Management.
 1.5. Definición consensuada de Gestión de Programa
Como ya se ha comentado previamente, existe poco consenso en la Comunidad de Práctica
Internacional de la Gestión de Programa en torno al término, pero, existen varias definiciones
recogidas por el docente, que atrapan el espíritu de esta práctica profesional:

1. “Una Organización temporal y flexible creada para la coordinación, dirección y supervisión de

la implementación de un conjunto de Proyectos relacionados y actividades con el objetivo
de producir ciertos “outcome/es” (“capacidad/ es”) y beneficios vinculados con los objetivos
estratégicos de la Organización” (traducción libre a partir del Gabinet Office, M.S.P., U.K. 2.007)

La Gestión del Programa va mucho más allá de la gerencia de múltiples Proyectos.

Todo parte de la definición de objetivos a largo plazo (estratégicos) de la Organización.

A partir de ahí se identifican los Programas de Proyectos que permiten la consecución de

dichos objetivos estratégicos, y se reflexiona con cuidado a cerca de los beneficios específicos
generados por cada Proyecto.

La Organización (su nivel ejecutivo) promociona una estructura organizativa para gestionar el
Programa y mantener en mente, de forma continuada, los objetivos estratégicos.

El tipo de Proyectos “componente” que integran el Programa propiciará, con toda probabilidad,
un cambio organizativo (“Programme Management” = “Change Management”) que afectará al
conjunto de la compañía. Después de todo, los Proyectos serán del tipo:

• Proyectos de Reubicación (“Relocation Projects”).

• Proyectos de Racionalización (“Rationalization Projects”).
• Proyectos de ReOrganización (“Reorganization Projects”).

2. “Un conjunto coordinado de Proyectos para la obtención de un cambio beneficioso de naturaleza

estratégica para una Organización” (traducción libre a partir “Introduction to Programme
Management”, Association for Project Management, U.K.)

3. “Gestión coordinada y centralizada para alcanzar los beneficios y objetivos estratégicos

establecidos para el Programa” (traducción libre a partir “Programme Management Standard”,
Project Management Institute, U.S.A.)

Todas estas definiciones de “Gestión de Programa” comparten cuatro elementos en común:

i. Múltiples Proyectos.

ii. Cambio Organizacional.

iii. Beneficios.

iv. Alineamiento Estratégico.

25
 Dirección de
proyectos 2. Otras definiciones de Gestión de
Programa. Valor para el negocio.
Procedentes de otros entornos, culturas
profesionales e industrias o sectores, se dan otras
definiciones posibles para el término de Gestión de
2. Otras definiciones Programa (“Program Management” en el ámbito
de Gestión de norteamericano y “Programme Management” en
Programa. Valor el ámbito británico).
para el negocio.
En particular se van a ver cuatro posibles
definiciones, las más comunes:

2.1. La Organización MultiProyecto

Bajo esta definición, la “Gestión del Programa”
consiste en la dirección de un grupo de Proyectos
por medio de un enfoque o acercamiento de gestión
consolidado.

Muchas Organizaciones implementan distintos

Proyectos de forma simultánea, pero no todos
contribuyen o están alineados con los objetivos
corporativos. Este tipo de Proyectos producen
el entregable/es por el que se constituyeron y
que transfieren al Cliente a cambio de un “pago”.
Después de un retraso considerable, la “orden de
pago” se hace efectiva en la cuenta bancaria de la
compañía, incrementando, por tanto, la “caja” o
“tesorería” de la misma.

En otras ocasiones, sin embargo, los Proyectos

están más vinculados a los objetivos corporativos
(por ejemplo: la apertura de una nueva planta
de producción –ampliación de la capacidad de
manufactura- o el desarrollo de un nuevo producto
–penetración de mercado-).

Los elementos comunes de los Proyectos que caen

bajo esta consideración de Gestión del Programa
es que son gestionados de forma simultánea (o al
menos se da cierto solape), comparten recursos
y que generan beneficio o riqueza económica
(“income”).

Por último, es importante resaltar que la

cancelación de un Proyecto componente del
Programa no tiene por qué modificar o alterar la
Dirección General de la Compañía.
2.2. El MegaProyecto
Esta definición hace referencia a la gestión de un grupo de Proyectos hacia un objetivo
específico, por lo que, Programme Management puede también significar un único Proyecto de
gran complejidad y envergadura.

La “Misión Apollo XI” responde perfectamente a dicho perfil o definición de Programa. Se

trata de un Programa de gran escala, tremendamente complejo, que estuvo integrado por un
elevado número de Proyectos “componente”. El término Programa aquí tiene tal “auténtico
sabor USA”, que conviene utilizar el término “PROGRAM” frente al término “PROGRAMME”
(propio del contexto británico).

Dentro del “Programa Apolo” se dieron muchos y muy diversos Proyectos:

• El “Lunar Lander”.

• El “Orbiter”.

• El “Launcher”.

• El “Control Systems”,

Todos estos Proyectos fueron de tal complejidad y envergadura, que cualquier Project Manager
de “sangre caliente”, apasionado de la disciplina del Project Management, hubiera deseado de
forma ferviente estar involucrado en la gestión de los mismos.

En el contexto norteamericano de Defensa, Seguridad, Militar y Aeroespacial, “Polaris Project”

y “Manhattan Project” (el cual dio como resultado el desarrollo de la “Bomba Atómica”) son
otros dos Proyectos también de larga escala que pueden ser denominados Programas (o
“Programs”, en inglés USA).

En consecuencia, en el contexto norteamericano, el término “Program” se refiere a un conjunto

de Proyectos relacionados, cada uno de gran complejidad y suficiente escala o envergadura,
que a su vez componen un único gran “super-Proyecto”.

De esta manera, este enfoque de Programa se refleja en la estructura de gestión, de forma

que, un Gerente de Programa (Program Manager, a veces también Program Director) dirigirá
(integración) la gestión de cada uno de los Project Managers.

El papel clave del Program Manager / Director está en la constitución y desarrollo de Equipos
de Gerencia de los Proyectos “componente” y la integración de los entregables producidos por
cada Proyecto en el conjunto del Programa (Program).

Bajo este enfoque de Program Management, la probabilidad de existencia de entregables

físicos es muy elevada.

Resulta crítico comprender que estos tipos de Programas siempre alcanzan un final, es decir,
llegará el momento en que el objetivo conjunto del Programa se haya conseguido, dándose por
cerrados tanto el Programa como los Proyectos componente.

Las conexiones entre los Proyectos constituyentes de este tipo de Programas son especialmente
relevantes, de forma que, retrasos en un Proyecto tiene un impacto inmediato en los Proyectos
conectados con él (debido a las relaciones de precedencia lógica establecidas entre actividades
o tareas de Proyectos relacionados).

27
2.3. Muchos Proyectos para un mismo Cliente
Esta definición de Programa se refiere a la gestión de una serie de Proyectos dentro de una
Organización para un mismo Cliente.

Para una mejor comprensión de este enfoque o definición de Gestión de Programa se presenta el
micro-caso de Triplex, Girling y Lucas, todos ellos proveedores de la firma líder en automoción
FORD.

Los tres proveedores especializados nombrados, producen una amplia variedad de componentes
que son diseñados en colaboración con fabricantes de vehículos. Este partneship o colaboración
se da en Secret (Warrington, Lancashire, U.K.) donde los especialistas en diseño de automoción
afrontan el desarrollo de nuevos modelos FORD o la renovación (última versión) de modelos
existentes.

Triplex, perteneciente al Grupo Pilkington, podría estar trabajando en el modelo “Fiesta”

(el modelo actual), el “Focus” y el “Transit Van” de forma simultánea, pero, los tres Project
Management Teams (uno por cada modelo), estarían trabajando/colaborando con tres Equipos
de Proyecto de FORD.

Triplex decide con antelación, previendo la complejidad de los trabajos de colaboración con
los Equipos de Ford (y por lo tanto las interacciones existentes), la agrupación de los tres
Proyectos relacionados en forma de Programa y el nombramiento de un Gerente de Programa,
encargado de la integración del trabajo de los tres Project Managers.

De esta manera, cualquier solución de diseño nacida al abrigo de uno de los tres Equipos de
Gestión de Proyecto de Triplex (Pilkington), que se demuestre creativa y eficiente, se transferirá
a los dos Equipos restantes.

Los especialistas de Ford (diseño) que trabajan con los tres Equipos de Gestión de Proyecto de
Triplex, trabajan de forma parcial (“part-time”) en los tres Proyectos mencionados.

En este tipo de Programas quizás no esté totalmente justificada la conexión y, por lo tanto, la
agrupación de los Proyectos, pero, con total certeza, compartirán los mismos recursos. Muy
seguramente dichos Proyectos son gestionados por diferentes Project Management Teams
dentro de la Organización que resulta adjudicataria del contrato de servicios de gerencia, unos
Equipos que, con toda probabilidad, también, compartirán Departamentos Funcionales.

2.4. Compañías orientadas a Programme Management

Esta definición recupera las reflexiones previas en torno al concepto de “Programa de Cambio”.

En esta ocasión, el término “Programa del cambio” hace referencia a la gestión de un grupo de
Proyectos que apuntan hacia los objetivos corporativos de la Organización, el apoyo coordinado,
planificación, priorización y supervisión de Proyectos; todo ello para cumplir con los objetivos
de cambio (negocio) establecidos (“Change Management”).

Las Compañías que ponen en práctica la “Gestión de un Programa de Cambio” (“Change

Management Programme”) implementan “Proyectos de Cambio Organizacional”
(“Organizational Change Management Projects”) de forma simultánea, cada uno de ellos
trabajando sobre objetivos estratégicos específicos de la Organización. Estos Proyectos están
conectados tanto de forma lógica, como por recursos compartidos, siendo habitual que los
entregables de ciertos Proyectos (“outputs”, “salidas”) sean “inputs” (“entradas”) de otros
Proyectos subsecuentes.
 Este grado máximo de interacción entre “Proyectos de Cambio Organizacional”, pertenecientes
todos ellos al “Programa de Cambio de la Organización”, tiene un impacto directo en los
Departamentos Funcionales, siendo habitual una “batalla” continua por los recursos
compartidos entre todos los Proyectos.

Con frecuencia, según los Proyectos finalizan, el conjunto de objetivos corporativos es

nuevamente revisado.

2.5. Conclusiones
Una vez analizados las cuatro definiciones de “Gestión de Programa” más habituales, en el
entorno Empresarial actual, puede llegarse a la conclusión sobre la existencia de puntos en
común entre todas ellas:

• Simultaneidad de muchos Proyectos.

• Programas integrados por Proyectos intensivos en recursos (compartidos).
• Visión “multi-Proyecto” de Scheduling (Programación Cronograma).
• Planificación del Programa de Proyectos (“Programme Planning”).
2.6. Tipos de Proyectos
En una reunión acalorada de Project Managers es frecuente observar ceños fruncidos, cejas
levantadas y caras de perplejidad. Muchas veces parecen estar discutiendo de forma inteligente
sobre ciertas incidencias o problemáticas de gestión del Proyecto en curso, pero en muchas
otras parecen hablar lenguajes distintos.

Si este grupo está integrado por Gerentes procedentes de la misma industria o sector (y, por lo
tanto, comparten el mismo “approach” gerencial), y si pueden intercambiar roles de gerencia,
los problemas potenciales finalmente no aparecerán.

Sólo cuando se mezclan o integran Project Managers con diferente “background” sectorial
y profesional, aun empleando la misma terminología de Gestión de Proyectos, quieren decir
cosas bien distintas. Tras esta confusión se encuentra el tipo de Proyecto que tienen en mente.

En consecuencia, la naturaleza, tipología y acercamiento al Proyecto en curso condiciona de tal

forma su “approach” de gestión que puede provocar que una conversación inteligente resulte
de difícil manejo.

A continuación se presentan cuatro (4) tipologías de Proyecto que se pueden identificar en las
empresas.

2.7. Proyectos Internos y Proyectos Externos

Los “Proyectos Internos” se conciben para cambiar la Organización marco en el cual nacen, se
desarrollan y terminan. Ejemplos de “Proyectos Internos”pueden ser los siguientes:

• “Sistema de Gestión de Nóminas y Bonos”.

• “Nuevo Sistema de Información de Gestión”.

• “Proyecto de Re-estructuración Organizativa”.

29
 Por “Proyectos Externos” se entienden aquellos Proyectos que producen entregable/es
transferidos o entregados finalmente al Cliente. Este tipo de Proyectos contribuyen a los
objetivos de la Organización en el sentido de que traen beneficio económico a la misma, pero,
no cambian los procesos de negocio de la compañía.

En el límite de estas dos categorías de Proyectos se encuentra el “Proyecto de Desarrollo

de un Nuevo Producto”. En este tipo de Proyecto, el Equipo de Investigación y Desarrollo,
respaldado por el Equipo de Pruebas , el Equipo de “Prototipado” y el Departamento de
Marketing (responsable de la “prueba de mercado” del nuevo producto) conciben de forma
conjunta, coordinada e integrada el nuevo producto a desarrollar.

Para este caso, el Equipo de Gestión del Proyecto desarrolla la idea, testea el prototipo del
producto, define el marketing y canal/es de distribución, y lo transfiere al Departamento de
Producción.

¿Es este un Proyecto Interno o un Proyecto Externo? Depende. Depende de la naturaleza del
producto, la relación entre el Equipo de I+D y el Departamento de Producción, así como, la
forma en la que el Proyecto es implementado.

2.8. Proyectos Materiales y Proyectos No Materiales

“Material” frente a “no material” trae a la palestra una clara diferencia semántica con
implicaciones sutiles.

Constructores, Ingenieros Civiles, Arquitectos, Ingenieros Electromecánicos, etc.; todos ellos,

producen entregables físicos(bienes materiales, tangibles, palpables), es decir, operan con
“Proyectos Materiales”.

Los profesionales, técnicos y de gestión, de dichas especialidades (Construcción, Ingeniería,

Instalaciones, etc.) tienen la facultad de alcanzar altos niveles de motivación y compromiso
con tales objetivos de Proyecto pueden visualizarlo antes del inicio del Proyecto.

En este marco, muchos Equipos de Gestión de Proyectos comprenden la necesidad de contar

con un “modelo” o reproducción a escala del bien material objeto del Proyecto. Es fácil sentir
la satisfacción de estos profesionales cuando, con el cierre del Proyecto, el entregable/es es/
son transferido/os al Cliente, cumpliendo las especificaciones de calidad, el plazo programado
y el coste previsto.

Podría decirse que los profesionales técnicos y de gestión a cargo de Proyectos “No Materiales”
no cuentan con la misma suerte. Dichos perfiles parten sin una imagen o prototipo mental
del objetivo (resultado, entregable/es) del Proyecto, una situación propia, por ejemplo, de los
Equipos de Desarrollo de Aplicaciones Informáticas o Software, para los que el entregable/
es final cabrá en un “stick” de memoria o USB. Así, el objetivo del Proyecto (su resultado, el
entregable/es) podría consistir en un Informe de miles de hojas de extensión, con la jerga tan
propia de esta área. “Poco excitante” son palabras que se quedarían cortas a la hora de valorar
la “falta de impacto” inicial que produce esta perspectiva.

El grupo de procesos de gestión “supervisión y control” provoca un “pequeño” problema en la

gestión de los “Proyectos No Materiales”. Mientras Constructores, Arquitectos o Edificadores
computan ladrillos, Ingenieros Geotécnicos cuantifican metros de túnel e Ingenieros Civiles
verifican la resistencia del hormigón estructural, ¿qué computa, verifica o comprueba
 el Ingeniero de Desarrollo de Software? Los profesionales implicados en “Proyectos No
Materiales” ingenian singulares medios de cómputo, verificación o comprobación, de forma
que, puedan medir el progreso o avance del Proyecto de una manera, artificialmente, efectiva.
Métricas como las “líneas de código” son habitualmente usadas en la industria del Software.

El “Proyecto No Material” comparado con el “Proyecto Material”, como es el caso del desarrollo
de software, es “como construir un chalet adosado dentro de una caja de zapatos”. No se puede
observar a través de la caja cómo marcha el Proyecto pero se puede preguntar en alto sobre la
marcha del mismo y recibir una respuesta positiva. De pronto, un día, poco relacionado con la
fecha de finalización estimada del Proyecto, la caja desaparece y en su lugar surge, de forma
inesperada, un entregable de una envergadura no adivinada a través de la caja (del tamaño de
un bien como el producido por el Proyecto Material, por su magnitud).

La planificación habitual suele fallar en Proyectos de Desarrollo de Software. Se puede

planificar por completo un “Proyecto Material”, porque del resultado esperado (bien material,
tangible, palpable) el Equipo de Gestión es capaz de idear un modelo o prototipo (representación
a escala del entregable físico final) que le permite al equipo realizar todo tipo de previsiones
y estimaciones. El enfoque de gestión basado en la descomposición del alcance del Proyecto
(entregable/es) hasta el nivel de “paquetes de trabajo” es de franca utilidad en el manejo de
un “Proyecto Materia”l. Una vez que el alcance queda perfectamente conocido o delimitado,
tiempo y presupuesto son las dos principales “obsesiones” del Equipo de Gerencia.

Por el contrario, dado un Proyecto abierto cuyo entregable es “no físico” (“Proyecto No Material”),
el software de planificación (“planning software”: MSProject, Primavera, etc.) acabará en la
papelera, al demostrarse ineficiente en un Proyecto de esta naturaleza, como es el caso de un
Proyecto de Desarrollo de Aplicaciones Informáticas. El software de planificación únicamente
distraerá al Equipo de Gestión del Proyecto de los auténticos objetivos del mismo. El verdadero
reto del Líder de Equipo consiste en conseguir una elevada motivación del Equipo. Nada hay
más desmotivador para un Equipo de Gestión de un “Proyecto No Material”, todo un Proyecto
abierto, que la existencia de un Plan de Dirección de Proyecto, fijo y estático, a cumplir. Este tipo
de planes apunta al “Tiempo” como objetivo del Proyecto, un enfoque de gestión inadecuado
para “Proyectos No Materiale”s abiertos donde se requiere de una “agilidad” (“agility”) total.

2.9. Beneficios
Como ya se ha comentado, los Programas están diseñados para la entrega de “outcomes”
en forma de “capacidad” o “capacidades” de negocio para la Organización, y la medida de
éxito (grado de consecución, logro o realización) de dichos “outcomes” son los “beneficios” (de
negocio). Unos “beneficios” que son disfrutados por la Organización tiempo después de que el
Programa haya finalizado (cierre o terminación).

Los beneficios tienen su impacto en el conjunto de la Organización, nunca en un Proyecto,

Programa y Portfolio particular.

Se presentan a continuación algunos ejemplos habituales de beneficios de negocio:

• “Incrementar el número de Clientes”.

• “Incrementar el nivel de satisfacción del Cliente”.
• “Aumentar la eficacia de la compañía” (logro de objetivos o metas).
• “Mejorar la capacidad de fabricación de un producto” (“manufacturability”).
• “Mejorar el “branding” de la Organización”.

31
• “Elevar la moral de la Compañía”.
• “Reducción de ineficiencias en procesos de negocio”.
• “Reducción de los costes de transporte/logística”.
• “Elevar la captura de conocimiento desde los sistemas de información de la gestión”.

La rentabilidad depende de todo un conjunto de factores, cuya evaluación o valoración no

siempre resulta sencilla.

Por ejemplo, una compañía podría implementar un Proyecto para “elevar el nivel de facturación
o ventas en un 10%”, pero inducir, al mismo tiempo, una peor aceptación (perjudicial para la
“decisión de compra”) por parte del potencial Cliente. Ante esta disyuntiva, la compañía debe
comparar el coste del Proyecto con el impacto estimado del éxito del mismo sobre la “cuota
de mercado” (“market share”).

El “estudio de alternativas”, “análisis de viabilidad”, “evaluación de la rentabilidad económico-

financiera”, etc.; de este tipo de disyuntivas, algo tan propio de la actividad Empresarial, resultan
del todo reveladoras. En este sentido, las Organizaciones evalúan los “pros” y los “contras” de
cada Proyecto “componente” o de una combinación de Proyectos “componente” en forma de
Programa (la gestión “consolidada” de varios Programas habla de la Gestión del Portfolio), una
evaluación que surge de cuestiones como “¿debería acometerse tal inversión para ganar una
cuota de mercado de determinado porcentaje?”

Un Sponsor de un Proyecto o Programa particular, cuyo éxito traiga como beneficio/os alguno
o algunos de los ejemplos presentados más arriba, se convierte en un auténtico “promotor”
de la idea, y, por lo tanto, del Proyecto o del Programa. Es un rasgo muy humano esa especie
de “optimismo”, cuando se trata de la exploración o desarrollo de nuevas vías, alternativas,
etc. Inevitablemente se aprecia, de forma única, el lado positivo de la propuesta de negocio,
ignorando o infravalorando, en paralelo, los peligros, incertidumbres o riesgos que conlleva (en
inglés se diría que el sponsor es un “overseller”). En este contexto, se están exagerando los
“beneficios” previstos.

Si un Sponsor promociona una idea o propuesta de negocio (Proyecto único o Programa) ante
el Comité Ejecutivo de la compañía (Committee Board, Senior Management o C-Level) en base
a un supuesto incremento en la facturación de, por ejemplo, el 15%, y posteriormente, una
vez finalizado el Proyecto o Programa, el incremento de ventas final auditado es del 12%, el
Comité Ejecutivo habrá visto sus expectativas (finalmente aprobaron la propuesta de negocio,
convencidos por el Sponsor) no cumplidas.

Por lo tanto, es recomendable tornar más realista el beneficio esperado para el Proyecto o
Programa cuando se presenta la propuesta de negocio ante el Board of Directors, pero con
el especial cuidado de no rebajar en exceso el “beneficio” esperado de forma que no resulte
atractivo para el Nivel Ejecutivo de la compañía, quien tiene la última palabra sobre el
lanzamiento del Proyecto o Programa.
 Dirección de
proyectos
3. Órganos de Gobierno Estratético de
Poryectos (P.M.O)
3.1. Introducción
La combinación de siglas P.M.O., tan en boga
en el ecosistema internacional del “Project
3. Órganos Management” desde la transición del siglo XX
de Gobierno al siglo XXI, en su acepción más completa, hace
Estratégico de referencia a “PROGRAMME, PORTFOLIO &
PROJECT MANAGEMENT OFFICE”, que,
Proyectos (P.M.O)
traducido al español, quiere decir “Oficina de
Gestión de Programas, Portfolios y Proyectos”; de
forma que, la propia nomenclatura establece una
relación directa entre esta Unidad y la Estrategia
de la Organización.

El papel clásico cumplido por la P.M.O. dentro de

la Organización ha sido el de soporte en materia
de:

• Tareas administrativas.
• Manejo de la Información.
• Procesamiento de Datos.

Estas tres funciones son las tradicionalmente

acometidas por una única persona responsable
de una P.M.O. que maneja un número reducido
número de y cuya complejidad, además, no es
relevante. Dicha persona ocupa el puesto de
“Programme Office Manager” (“Gerente de Oficina
de Programa”). En este caso, hoy se habla más
de “Global Centre of Project Excellence” (“Centro
Global de Excelencia de Proyecto” dentro de una
Organización) que de “P.M.O.”, sobre todo en el
contexto británico.

Sin embargo, cuando la Organización maneja

grandes Programas y Portfolios, es decir,
en Organizaciones de gran envergadura
(principalmente corporaciones), es entonces
cuando se habla de

P.M.O. en puridad, es decir, de una “PROGRAMME,

PORTFOLIO & PROJECT MANAGMENT OFFICE”.
Esta P.M.O. se caracteriza por manejar una cartera

33
(“Portfolio”) de Programas y Proyectos de gran complejidad, con un elevado número de
personas involucradas en su desarrollo.

De cualquier forma, si algo caracteriza el término “P.M.O.”, en el actual contexto global, es la

ambigüedad, y las múltiples acepciones o significados posibles dentro del ámbito Empresarial
y profesional.

• Necesidades de la Organización

• Complejidad

• Tamaño = Proyectos y Programas

• Cantidad

En esencia, la “Programme, Portfolio & Project Management Office”/P.M.O. varía en:

• Tamaño

• Sofisticación

• Responsabilidades

En la actualidad, en términos promedio, caracterizando las líneas de comportamiento

principales, se dan tres tipos de P.M.O.:

• PROJECT OFFICE

(“Oficina de Proyecto”)

• PROGRAMME MANAGEMENT OFFICE

(“Oficina de Gestión de Programa”)

• PORTFOLIO MANAGEMENT OFFICE

(“Oficina de Gestión de Portfolio”)

El término P.M.O. puede emplearse en las siguientes situaciones:

(1) Una persona con perfil “junior” que facilita cierto soporte administrativo a un único Project
Manager de Proyecto (situación “Oficina de Proyecto” –Project Office-)

(2) Un equipo centralizado que facilita soporte y dirección a todos los Proyectos incluidos en un
Programa (situación “Oficina de Gestión de Programa”)

(3) Un grupo humano que supervisa el Portfolio de Programas y Proyectos (situación “Oficina
de Gestión del Portfolio” –Portfolio Project Management-, u, “Oficina de Programa de Empresa”
–Enterprise Programme Office-).
Estrictamente, todo equipo que facilita sólo soporte administrativo representa una P.S.O.
(“Project Support Office”).

El término P.M.O. debe emplearse sólo cuando el equipo asume responsabilidades de

gestión.

A continuación se describen los tres tipos de P.M.O. principales indicados:

DE APOYO

Desempeñan un rol tipo consultoría para los proyectos, colaborando con plantillas,
procesos, gestión de la información… Siendo el grado de control reducido.

Soporte para 1 Proyecto o 1 Grupo pequeño de Proyectos relacionados.

Servicios: libera al Project Manager de las tareas administrativas. Información actualizada

y precisa para asegurar una correcta dirección del Proyecto

DE CONTROL

Proporcionan el soporte a los diferentes proyectos, teniendo un control moderado sobre

ellos para ello deben indicar a estos las metodologías, plantillas, formularios, herramientas
y manera de gestión en las que se deben realizar los trabajos

Esta Oficina maneja un Programa (= ∑ Proyectos relacionados) complejo en una Organización

ya de cierta envergadura. Dan soporte a un Equipo de Gestión de Programa.

Las tareas que realiza son las propias de la “Project Office” (P.O.) más el soporte extra que
todo Programa requiere para atender la gestión integrada de los “Proyectos componente”
(“Component Projects”).

Servicios: Benefit & Change management (gestión del cambio y de los beneficios), entrega
a tiempo de Proyectos y coordinación del cambio, estándares, procedimientos, guías,etc.

DIRECTIVA

Este tipo de Oficinas ejercen todo el control de los diferentes proyectos o programas siendo
el grado de control sobre estos elevado.

Se trata de la forma más sofisticada de P.M.O.

Sirve todas las funciones de la “Programme Management Office” u “Oficina de Gestión del
Programa” más una supervisión de nivel sénior sobre:

• Portfolio completo de Proyectos, o,

• División o Unidad de Negocio.

Servicios: estándares para Proyectos y Programas, guía al Nivel Sénior de la Organización

en materia de priorización de inversiones en nuevos Proyectos y Programas, aconseja
sobre la fusión, posposición o cancelación de iniciativas no alineadas con la ESTRATEGIA
de la Organización.

Esta jerarquización o clasificación de las tres principales tipologías de P.M.O. pretende

caracterizar “actitudes promedio” en el contexto internacional de la Gerencia de Proyectos,
pero, debe resaltarse que toda Organización es diferente, y que los atributos de una P.M.O.
depende de sus objetivos, responsabilidades y estructura, todos ellos reflejo de la propia

35
 Organización en la que está integrada, y por lo tanto, reflejo de la terna: (1) misión, visión y
valores, (2) objetivos de negocio (estratégicos), y, (3) Estrategia de la Organización.

De esta forma, el papel y los resultados esperados para la P.M.O. difieren según sea la
Organización en la que está integrada.

Es muy habitual que la P.M.O., mejor dicho, sus integrantes, estén distribuidos por el
conjunto de la Organización, de forma que:

• Unos integrantes supervisan el alineamiento estratégico (nivel Portfolio).

• Otros integrantes dan soporte a Project Managers individuales.

La percepción sobre la P.M.O. dependerá de la posición relativa del observador que la

valora o enjuicia dentro de la Organización.

3.2. Definición de oficina de gestión de proyectos

P.M.O.: “Unidad organizacional que facilita ciertos servicios centralizados que, dependiendo de
las necesidades de la Organización y del entorno, incluyen elementos de gestión y dirección;
siendo el objetivo de la Oficina la mejora en la eficacia y en la eficiencia de los Proyectos a su
cargo”.

De esta definición propuesta debe rescatarse 3 elementos centrales:

1. Servicios centralizados.
2. Gestión y Dirección.
3. Mejora en la eficacia (resultados/objetivos) y eficiencia (optimización de recursos).

En torno a esta propuesta de definición de P.M.O. caben las siguientes reflexiones:

• No se presupone nada sobre el tamaño de la unidad (P.M.O.) o su estructura. Podría

ser una persona o todo un departamento.
• Los servicios dependerán de las metas o el valor añadido esperados para la P.M.O.
Eso sí, se trata de algo más que meras tareas de administración.

Se observan muy diferentes nomenclaturas de P.M.O. válidas, hoy, en el ámbito profesional.

Véase:

• PROJECT CENTRE OF EXCELLENCE

• PROJECT MANAGEMENT OFFICE
• PORTFOLIO OFFICE
• PROGRAMME & PROJECT SUPPORT OFFICE
• PROJECT SUPPORT OFFICE
• ENTERPRISE PROGRAMME OFFICE
• PROGRAMME OFFICE
La falta de consenso no sólo es relativa al “nombre y apellidos” identificativos de la P.M.O.,
sino a su papel y a las responsabilidades que sustenta.

Las funciones principales de una PMO son las siguientes:

 • Gestión de recursos (entre los diferentes proyectos que son gestionados por la misma).
• Metodología, prácticas y estándares para la dirección de proyectos.
• Formar, orientar y supervisar.
• Control del cumplimiento de las políticas y procedimientos establecidos.
• Comunicación entre proyectos.

Es un HECHO COMPROBADO la ESCASA CORRELACIÓN entre la NOMENCLATURA y las

FUNCIONES acometidas por la P.M.O.

En este punto, cabe realizar las siguientes OBSERVACIONES a la “problemática” de la

definición de la P.M.O.:

1. El objetivo de implementar y operar una P.M.O. es obtener una serie de beneficios clave
para el conjunto de la Organización (se desarrollará en el próximo apartado “Por qué
implementar una P.M.O.”). La definición de P.M.O. aquí propuesta, asume el manejo de
múltiples Proyectos, en línea con la Gestión de Programa (o múltiples Programas) o la
Gestión del Portfolio.

2. Por lo tanto, se excluye cualquier unidad P.M.O. que dé soporte a un único Proyecto (=
”Project Office” / “Oficina de Proyecto”).

3. Si bien la gestión y control en una P.M.O. están centralizados, los servicios facilitados
podrían darse de forma descentralizada.

Por ejemplo, es muy frecuente encontrar Organizaciones con múltiples P.M.O’s, tanto a nivel
Ejecutivo (“P.M.O. Corporativa”) como de Departamentos específicos (“P.M.O. Departamental”),
asistidas por oficinas subordinadas para el manejo de Proyectos o Programas individuales
(se remite al capítulo posterior “El tamaño importa”).

3.3. Implementación: Nivel Programa y Nivel Portfolio

No todas las Organizaciones lanzan una P.M.O. por restricciones presupuestarias o por
consideraciones de – elevado- coste, así:

1. Organización de pequeña estructura y Gestión de pocos Proyectos: la P.M.O. resulta

“prescindible” (= Coste + Burocracia)

2. Grandes Organizaciones y Gestión de Programas (o múltiples Proyectos): Implementan

P.M.O.

Los estudios actuales1 muestran que cerca de tres cuartas partes del total de Empresas
británicas (U.K.) implementan una P.M.O.

Otros estudios2 confirman la misma tendencia en Empresas de Estados Unidos y a escala

internacional (fundamentalmente grandes Organizaciones).

1. Cranfield University, School of Management. International Centre for Programme Management at Cranfield,U.K. (2913). “tO Have or
Not to Have a PMO - Is that the Right Question?” Cranfield University (,U.K.)

2. ESI International (2011). “ The Global State of the P.M.O. in 2011: Its Value, Efectiveness and Role as the Hub of Training”. An ESI
International Study. www.esi-intl.com

37
El ¼ restante de las Organizaciones, aun así, implementa servicios o funcionalidades del tipo
P.M.O. (sin constituir formalmente la “unidad” P.M.O. como total). Por ejemplo:

Resulta CLAVE aclarar que no todas las Organizaciones están orientadas a Proyectos (“Project-
driven or Project- oriented Organizations” u “Organizaciones Proyetizadas”).

DE HECHO, muchas Organizaciones se guían por procedimientos de negocio tradicionales

(“business-as-usual procedures”), en consecuencia, no reconocen el “valor añadido” de
gestionar el cambio (“Change Management”) en forma de “Proyectos discretos”.

Es una práctica HABITUAL el que 1 ó 2 de los Project Managers más expertos de la Organización
asuman el papel de “Project Office”, una especia de “Project Office Virtual” u “Oficina Virtual de
Proyecto” que realiza las siguientes funciones:

• Dar soporte a otros Project Managers.

• Guiar en la gestión del Portfolio de la Organización.

PERO, no hay duda de los BENEFICIOS derivados de la implantación de una P.M.O. en una
Organización, tanto si se gestiona un único Programa, como si se gestiona todo un Portfolio.
Así lo confirman los estudios (ver las dos notas al pie de página).

A continuación se indica, de forma detallada, los beneficios de implementar una P.M.O., primero
para nivel Programa, y segundo, para nivel Portfolio.

3.3.1. Nivel programa

1. Profesionaliza la dirección de Programas (formal – “best practices”) mediante estándares
y terminología comunes, reduciendo así el riesgo de fallo de Proyecto (entrega en tiempo,
coste y calidad).

2. Mejora de la gobernanza del Programa a través de un estándar consistente a la hora de

informar del avance, riesgos, problemas, etc. (se asegura un alineamiento continuo con la
Estrategia).

3. Mejor soporte a los P.M. a través de técnicas, procedimientos, etc., en materia de project
management.

4. Supervisa la calidad y conveniencia de las herramientas de gestión de Proyecto, programa

y portfolio de la Organización (planificación , gestión de documentos y herramientas de
colaboración).
5. Mejora de eficacia a través de enfoque “resultadista” (por objetivos) mediante la
“especificación de coste y tiempo” en el Proyecto individual.

6. Mejora de la eficiencia al maximizar el uso de recursos y evitar el esfuerzo duplicado

(=coordinación efectiva de la demanda de recursos de los Proyectos dentro de un Programa).

7. Centraliza las actividades de soporte o administrativas.

3.3.2. Nivel Portfolio

Asegura un proceso consistente y efectivo de revisión del CASO DE NEGOCIO (“Business
Case”) tanto a nivel Proyecto como a nivel Programa: solo aquellos Proyectos o Programas
que generarán riqueza para la Organización serán autorizados.

Se entiende entonces la relevancia que adquiere la P.M.O. en la INICIACIÓN de un Proyecto.

La P.M.O., cuando está institucionalizada dentro de la Organización, hace de “Sponsor” del
Proyecto y comanda los primeros.

pasos en el desarrollo del mismo, aportando tres (3) documentos clave, que además se anexan
al Project Charter o Acta de Constitución del Proyecto:

• Declaración de Alcance del Trabajo( S.O.W., Scope of Work Statement).

• Contrato –para “Proyecto Externo” (Cliente fuera de la Organización) o encomienda de

trabajo (encargo) –para “Proyecto Interno” (Cliente dentro de la Organización, la P.M.O.)

• Caso de Negocio (“Business Case”).

Asegura una supervisión permanente de los Proyectos y Programas en curso, verificando el

alineamiento estratégico de los mismos.

Se presenta a continuación un modelo de ponderación del impacto estratégico de los Proyectos

de la Organización (véase gráfico inferior).

39
El cometido de aseguramiento del “encaje estratégico” es propio de las fases previas al
desarrollo del Proyecto, es decir, cuando la P.M.O. evalúa la viabilidad del Proyecto desde
todos los ángulos (operativo, técnico, comercial y económico), siempre bajo el paraguas de la
Estrategia de la Organización.

Se observa, en la columna de la izquierda, los objetivos estratégicos procedentes del Plan

Estratégico de la Organización, y que se convierten directamente, para este modelo, en los
criterios de priorización de Proyectos. A cada criterio (objetivo estratégico) se le da un peso,
representando éste su aporte o relevancia en el conjunto del modelo.

Cada Proyecto “componente” del Programa y/o Portfolio (según estructure la Organización
sus iniciativas) –“Component Project”–, es evaluado de forma individual siendo calificado en
cada criterio de priorización (en este caso según una escala de puntuación del 0 –sin impacto–
al 9 –impacto máximo–). Finalmente, cada Proyecto obtiene una calificación ponderada total.
Se priorizarán aquellos Proyectos que mayor “total ponderado” tengan.

La siguiente gráfica tiene especial relevancia a la hora de entender la progresión del valor
facilitado por la Oficina de Gestión del Portfolio, Programa y Proyecto al conjunto de la
Organización. Según este gráfico, la P.M.O. madura y se consolida a lo largo de cuatro niveles,
con un valor incremental creciente, y una responsabilidad, también, creciente. Puede ser
entendida como la “CURVA DE APRENDIZAJE” de la P.M.O.
La “Curva de Aprendizaje” muestra la evolución del papel de la P.M.O. dentro de la Organización,
desde el nivel 1 en el que únicamente tiene un cometido de “reporte de Proyecto” (recopilación
de datos, registro), pasando por el nivel 2 de ejecución y control del Proyecto, en el que
maneja de forma eficaz el control integrado del cambio (C.I.C.), y por lo tanto domina la
gestión integral del Proyecto (área de Integración), alzándose hasta el nivel 3, de una mucho
mayor complejidad, donde maneja ya la cartera o Portfolio de Proyectos de la Organización
(agrupados en forma de Programas), lo que implica una gestión coordinada e integral (manejo
de todas las interrelaciones posibles entre Programas y Proyectos), hasta, finalmente, escalar
al nivel de mayor sofisticación de servicios provistos (y, por tanto, de madurez), el nivel 4 de
la “Curva de Aprendizaje”, en el que la P.M.O. provee a la Organización del aseguramiento
del encaje estratégico del Portfolio (con la Estrategia de la compañía) y la Gestión de los
Beneficios (“Benefits Realization Management”), en línea directa con el cumplimiento de los
“objetivos estratégicos” de la Organización.

Del gráfico se desprende cómo los tres saltos graduales entre los cuatro niveles de la “Curva
de Aprendizaje” de laP.M.O. dentro de la Organización suponen un valor añadido incremental,
mayor, proporcionado por la P.M.O. al conjunto de la compañía; así como, en paralelo, una
responsabilidad creciente, desde un perfil administrativo de Proyecto hasta otro de consejo y
recomendación a la Dirección Ejecutiva de la Organización.

A continuación se presenta un esquema de “Beneficios Genéricos” sobre la Organización

derivada de la implementación de la P.M.O.

41
Dicho esquema se caracteriza porque:

• Los servicios facilitados por la P.M.O. aparecen en la 1ª columna (izquierda)

• Dichos servicios provocarán cambios en la línea de gestión de Proyectos, Programas y
Portfolio de la Organización (2ª columna)
• Los cambios traerán consigo ciertos “beneficios” (columna central, la tercera por la
izquierda).
• Se denominan “beneficios aislados” (“isolated benefits”) ya que se identifican de manera
individual o independiente unos de otros
• Pero, los beneficios nunca se materializan de forma aislada, sino, interrelacionada entre
ellos (“beneficios integrados” o “integrated benefits”), ya que dependen unos de otros (4ª
columna por la izquierda)
• La consecuencia global es que la obtención de dichos beneficios resultará en la consecución
de los “objetivos estratégicos” de la Organización (última columna de la derecha).

No debe perderse en ningún momento de vista el objetivo por el que se implementa una P.M.O.
en una Organización:

OBJETIVO P.M.O = AYUDAR A OPTIMIZAR LA INVERSIÓN EN EL PORTFOLIO DE

PROGRAMAS Y PROYECTOS
 Una “obsesión” dentro del ecosistema del “Project Management”,
cuando se trata de implementar una P.M.O. en una
Organizaciónqueinicialmentenocuentaconellayseplanteaesteauténticoreto(“Cambio
Organizativo”/”Organizational Change”), es la cuantificación de los beneficios para la Compañía
derivados de la implementación de la propia P.M.O.

1. PM Solutions, LLC (USA) estima que las Organizaciones con P.M.O. “maduras” tienen una
reducción de la probabilidad de “Project failure” (“crack”, “fallo/falla de Proyecto”) del
31%, y, una reducción del coste de entrega de Proyecto del 17%; con mejoras paralelas en
términos de “entrega frente a cronograma y presupuesto”.

2. Las mejoras sobre los “key financials” (indicadores financieros de la Organización) son
mayores cuando una madura P.M.O. tiene autoridad sobre el Portfolio completo.

La reducción de costes de Proyecto alcanza entonces el 8,6% el primer año hasta el 15,8%
durante el primer trienio3

El docente, D. Iván Zamarrón Mieza, presenta sus observaciones, a continuación, respecto de

la consultora

norteamericana PM Solutions, especializada en “P.M.O. services” (se recomienda al alumno

que analice, en paralelo, los estudios investigativos de esta firma en materia de P.M.O.):

• PM Solutions no es imparcial.

• El hecho de que algunas firmas hayan obtenido sustanciales mejoras no implica que todas
lo hayan hecho (el estudio muestra el potencial de mejora del conjunto del sector y no
tanto las mejoras reales ocurridas).

• El estudio está distorsionado ya que está orientada sólo a las I.T.’s, caracterizadas por
manejar amplios y dinámicos portfolios de Proyectos (guiados por consideraciones
tecnológicas), por lo tanto, con amplio margen de mejora.

La percepción del propio docente, D. Iván Zamarrón Mieza, consultor especializado en la

implantación de P.M.O.s en Empresas de la industria de la Construcción, compartida, por cierto,
con la mayoría de los profesionales consultores especialistas en la concepción, definición,
planificación, implementación y gestión de una P.M.O., es la siguiente:

MUCHAS ORGANIZACIONES, HOY TODAVÍA,

NO VEN EL VALOR AÑADIDO GENERADO POR LA P.M.0

A continuación se presenta un gráfico que resume una campaña de investigación 1 4 realizada

a mediados del año 2.010 entre 475 profesionales de tecnología en Estados Unidos, a los que
se realizó la siguiente pregunta:

“¿Cuándo un Proyecto debe ser gestionado por una P.M.O.?”

3. http://www.pmsolutions.com/collateral/research/

4. U.R.L. del Estudio de Investigación: http://reports.informationweek.com/abstract/83/4337/IT-Business-Strategy/research-

enterpriseproject-management.html

43
 Informative Week Analytics Enterprise Project Management Survey

(USA, 475 profesionales sector I.T.’s de compañía con P.M.O., junio 2010)

Del estudio se deriva que los principales factores que determinan la necesidad o exigencia de
la P.M.O. dentro de una Organización son los siguientes (por orden de prioridad o importancia
otorgada por los especialistas encuestados):

1. Grado de complejidad de los Proyectos gestionados a 49%.

2. Presupuesto asignados a los Proyectos (costes) a 38%.
3. Número de Unidades de Negocio, Líneas Operativas o Divisiones implicadas en la gestión
de los diferentes Proyectos a 26%.
4. Nivel de riesgo (probabilidad e impacto) de los Proyectos a 20%.
5. Cumplimiento con normativa (legal, ambiental, fiscal, etc.) a 8%.
6. Otras razones a 6%.

Curiosamente, un 25% respondió que todos los Proyectos de su Organización son dirigidos por
una P.M.O. ya implantada.

Después de este anailisis en 2014 Enterprise Project ManagementSurvey, se realiza la

siguiente pregunta

“¿La muerte de la Oficina de gestión de proyectos?”

 Presentando el siguiente gráfico:

De este grafico se pueden sacar diferentes conclusiones, pero a fundamental es que en

aquellas organizaciones en las que se ha establecido la oficina de gestión de proyectos, el 78%
sobrevive, indicando la necesidad de la misma.

3.4. El papel de la P.M.O

Como ya se ha indicado previamente, los estudios sectoriales muestran que no hay un estándar
único en los servicios provistos por una P.M.O.

No existe un único servicio facilitado por todas las P.M.O. de todas aquellas Organizaciones, a
escala internacional, que la tienen incluida en su estructura organizativa.

Los servicios típicos que proveen las P.M.O.’s son los siguientes:

• Reporte de estatus y avance de Proyecto.

• Promoción de estándares comunes en gerencia de Proyectos.
• Facilitación de elementos de control económico-financiero.

Se presenta a continuación un gráfico denominado “Servicios Típicos de una P.M.O.”5 resultado

de una campaña investigativa realizada entre junio y julio de 2.009 por la británica Asociación
de Project Management (“Association of Project Management”, A.P.M.), en particular su
comité o sección de “Programme Management”, campaña con la que se pretendía recopilar
los funciones realizadas por las P.M.O. Los datos fueron publicados en enero de 2.010 en la
publicación de referencia en el sector Project Magazine.

45
 De las 13 posibles funciones a acometer por una P.M.O., y sobre la que fueron consultadas
las Organizaciones objeto de la campaña de investigación, destacan las siete primeras (con
mayores porcentajes de puntuación):

1. Progress Reporting (reporte de avance)

2. Programme/Projects standarization (estandarización de Programa y Proyectos)
3. Accounting and Financial controlling (control contable y financiero)
4. Programme/Project governance (gobernanza de Proyecto o Programa)
5. Team Communications (gestión de las comunicaciones internas de equipo)
6. Administrative support (soporte administrativo)
7. Quality management/assurance/auditing (gestión, aseguramiento y auditoría de calidad)

La Universidad de Cranfield de Reino Unido cuenta con el “International Centre for Programme
Management (I.C.P.M.)”, uno de los grupos de trabajo o “think-tank”, dentro del ecosistema
internacional del “Project Management”, que más literatura ha producido en torno a la P.M.O.
en el ámbito Empresarial (sector privado) y en el público (agencias o administración pública).

5. Fuente: “PMOs and Portfolio Management – What leads to success”, Project Magazine, January 2.010)
 • Este grupo de trabajo especializado analizó la relación entre los “servicios provistos” y
el “alcance” de la P.M.O., produciendo en 2.013 un “White paper”6 (artículo técnico,
especializado) denominado “To Have or Not To Have a P.M.O. – Is That the Right Question?”
(J.Ward, T.Illingworth & A.Piplani, Cranfiled University, U.K., 2.013), el cual:

• Confirma la variabilidad de servicios provistos y las funciones asumidas por las distintas
P.M.O.s.

• Demuestra una tendencia hacia la jerarquización de los servicios, de forma que todas las
P.M.O.s hoy existentes facilitan un set de “servicios básicos” (comunes a todas las P.M.O.)
y, a parte, se dan otros servicios de mayor sofisticación, solo en Organizaciones con gestión
de Portfolio y/o Programa.

A continuación se presenta un gráfico en el que se sintetiza la jerarquización de los posibles

servicios a ofrecer por una P.M.O. desde el nivel

0 Servicios básicos
1 Servicios adicionales
2 Servicios de asesoramiento y consultivos
3 Estrategia y gobernanza

Esta “gradación” de servicios sirve también de caracterización o especificación de las funciones

de la P.M.O. (su papel exacto), según evoluciona sobre la “Curva de Aprendizaje” ya mencionada
previamente.

6. Cranfield University, School of Management. International Centre for Programme Management at Cranfield, U.K. (2013). “To Have or
Not to Have a PMO – Is that the Right Question?” Cranfield University.

47
3.4.1. P.M.O. Nivel 0 (“Servicios Básicos”)
Este es el perfil de la mayoría de P.M.O.s en el mercado, aquellas que sirven, únicamente,
soporte administrativo a Programme Managers y Project Managers. Se trata de los siguientes
servicios:

• Secretaría, gestión diaria y servicios de reserva (alojamiento, transporte).

• Reporte del status y grado de avance de Proyectos individuales.

• Reunión de la información de Proyectos en un reporte o informe global de todo el Programa

de Proyectos.

• Distribución de informes (Proyectos y Programas).

• Creación de estándares, métodos y procedimientos.

• Gestión documental (de Proyecto: Planes, Matrices de Riesgos, Cronogramas, Archivos de

Incidencias, etc.).

• Soporte a Sponsor/s (nivel “Gobernanza”) à Organización DE reuniones de Comité de

Proyecto/Programa, circulación de agendas y documentos del Comité, y, registro de actas
de reunión.

3.4.2. P.M.O. Nivel 1 (“Servicios Adicionales”)

Ciertas P.M.O. ofrecen, a su Organización, servicios más sofisticados, de mayor valor, en
particular los siguientes:

• Provisión de “juicio de experto” a Project Managers en la gestión de costes, programación,

comunicación y riesgos.

• Las P.M.O.s suelen estar integradas por especialistas en las áreas de conocimiento clave
del PMBOK: Master Scheduler, Master Cost Planner/Controller, Expert Risk Manager, etc.

• Supervisión de la coordinación entre Proyectos, lo que implica el control directo e integral

de los recursos compartidos.

• Control de ejecución de las líneas base de alcance, tiempo y coste.

• Gestión del cambio en el alcance de Programas y Proyectos.

• Verificación de que los estándares establecidos a nivel programa son cumplidos (calidad y
cronograma –tiempos-).
3.4.3. P.M.O. Nivel 2 (“Servicios Consultivos y de Asesoramiento”)
Este perfil de P.M.O. ofrece el más amplio conjunto de servicios (antes de entrar en Gobernanza
y Estrategia, correspondiente el al nivel 3), etiquetados como “Servicios Consultivos y de
Asesoramiento” (“Consultancy & Advisory Services”):

• Desarrollo de competencias del personal perteneciente a la Organización, lo que implica la

capacitación y mentorización de:

• Project Managers

• Sponsors

• Cualquier otro involucrado en la gobernanza de Proyectos y Programas en la

Organización

• Evaluación del Desempeño de los Project Managers de la Organización (marco del

Departamento de RRHH)

• Contratación y/o asignación de Project y Programe Managers, para alimentar el staff

interno de las grandes P.M.O.

• Control de ejecución de las líneas base alcance, tiempo y coste

• Registro, análisis y distribución de “lecciones aprendidas” (Gestión del Conocimiento)

• Medición de consecución de objetivos definidos (“cuadro de mando”)

3.4.4. P.M.O. Nivel 3 (“Estrategia y Gobernanza”)

Muy escasas en número son hoy las P.M.O. conocidas como “Full-service P.M.O.”, responsables
de la gestión de amplios y complejos Portfolios. Se trata de la P.M.O. deseada por el nivel
Sénior -generalmente grandes compañías, aquellas que cuentan con los medios y tienen la
visión inicial-. Se trata de una P.M.O. que trabaja codo con codo con el Nivel Ejecutivo de la
Compañía (Presidencia, Dirección General) facilitando servicios estratégicos (GOBERNANZA).

Los servicios provistos son:

• Identificación, selección y priorización de nuevos Proyectos y Programas (que conforman

el Portfolio de la Organización). Una función que puede resumirse en cuatro palabras, todo
un slogan clásico en el ámbito de la P.M.O.:

“ONLY THE RIGHT PROJECTS” (“Sólo los Proyectos adecuados”)

En este sentido, la P.M.O. enfoca su papel hacia:

• Benefits Realisation Management (B.R.M. –Gestión del Cumplimiento/Consecución de

Objetivos/Beneficios-)

• Business Case (Caso de Negocio)

• Contingencies (Riesgos)

• Adquisición y asignación de recursos entre Proyectos

• Consejo y recomendaciones a “Senior Management” (“Portfolio & Programme Boards”)

49
La P.M.O. sirve de orientación, guía y capacitación a Sponsors y miembros del Comité/
és de la Organización

• Realización de chequeos del Proyecto y/o Programa, revisión de “post- implementación”

como fuente de “lecciones aprendidas” ( Gestión del Conocimiento)

• Autocontrol: supervisión y control del propio trabajo de la P.M.O.:

• Análisis de su impacto sobre la entrega de Proyectos

• Análisis de su influencia sobre la consecución de los objetivos del Programa

Cuando se gestionan Programas y Proyectos estratégicos y son financiados por fuentes

distintas al propio Comité de Gestión del Programa, la P.M.O. prepara un informe síntesis de
la información clave del repositorio, obteniendo una foto a nivel Portfolio de los Programas
en curso.

A escala Portfolio, la P.M.O. centrará sus esfuerzos en tres vehículos de información clave:

• Portfolio-level Up-to-date roadmaps (hoja de ruta)

• Portfolio-level risk register (registro de riesgos)

• Portfolio-level Issue register (registro de inicidencias)

Para dichos documentos, la P.M.O. generará templates (plantillas, modelos, standards),

facilitando así la producción y distribución de los informes.

La información del repositorio es pública dentro de la Organización, exceptuando aquella de

carácter sensible, cuyo acceso solo está autorizado a los miembros del “Portfolio Board” (la
“mesa” responsable de la gestión de la cartera o del Portfolio de la Organización, una mesa
en la que se sienta el Director de la P.M.O.)

I. DOCUMENTOS CLAVE DE GESTIÓN DE PROGRAMA a almacenar en un espacio de

trabajo compartido (=sujetos a revisión y aprobación por el “Portfolio Board”)

• Resumen ejecutivo del Programa (“Programme Brief”)

• El “Caso de Negocio” del Programa y cualquier otra documentación de iniciación

• El “Plan del Programa” (“Programme Plan”)

• Cronograma

• Interdependencias con Programas y Proyectos relacionados

• Hitos críticos (fechas)

• Directrices de “quality assurance” (“aseguramiento de la Calidad”)

II. La INFORMACIÓN DE ESTATUS Y AVANCE del Programa incluye al menos:

• Cambios significativos en alcance, tiempo, coste y cualquier otro cambio en documentos

clave de Proyecto (“Beneficios esperados”, “Interdependencias entre Programas y/o
Proyectos”, etc.)
• Grado de avance real (ejecutado) frente a lo planificado (“línea base”) x “milestone trend
chart” (“gráfico de tendencia o evolución de hito/os”)

• Cambios relevantes en “Registro de Riesgos” (“Risk Register”) y “Registro de Incidencias”

(“Issue Log”)

• Nuevos riesgos o incidencias, cuya resolución requiera de su escalado al Comité de

Gestión del Programa

• Información Financiera (“Financial Status Report”)

Independientemente de la forma en que los servicios arriba descritos (servicios básicos, nivel
1, nivel 2 y nivel 3) sean provistos, las funciones y atribuciones de la P.M.O. deben estar bien
definidos, delimitados y comunicados al conjunto de la Organización.

La comunicación interna acerca del papel jugado por la P.M.O. en la Organización se realiza a
través del “Programme Charter” / “Portfolio Charter” (según el caso). La distribución de esta
información podrá ser asumida por la propia P.M.O. u otro agente dentro de la Organización.

Se presenta un ejemplo de un “Portfolio Charter” (“Acta de Constitución del Portfolio”) en el

cual se establece, de forma sintética, las responsabilidades de una P.M.O. de nivel Portfolio.

I. OBJETIVO IMPLANTACIÓN P.M.O.

MAXIMIZAR LA EFICACIA EN LAS ACTIVIDADES DE GESTIÓN DEL PORTFOLIO,

ASEGURANDO QUE LAS INVERSIONES ACOMETIDAS GENEREN EL MÁXIMO RETORNO
(BENEFICIO) PARA LA ORGANIZACIÓN

II. ALCANCE INICIAL DEL TRABAJO DE LA P.M.O.

SOPORTE ADMINISTRATIVO Y SOPORTE DE GESTIÓN DEL PORTFOLIO

III. OBJETIVOS DE LA P.M.O.

• ASEGURAR
• Clara comprensión por parte de los miembros del Comité de todos los puntos de la
agenda (una agenda avanzada con antelación para facilitar su lectura y discusión previa).
• Ágil circulación de acta de reunión del Comité o Sub-Comités establecidos.
• Fácil acceso – por personal autorizado – al repositorio en línea (actualizado
permanentemente) y a los documentos clave de gestión del Portfolio (Programme briefs,
Business Cases, etc.)*
* Incluirá la información clave de cualquier Proyecto o Programa “fondeado” fuera del
control del Portfolio Board
• Adecuado registro, distribución y presentación de reportes actualizados (información de
gestión) sobre el estado del Portfolio y de todos los Programas que lo integran:
• Estados Financieros (Balance, E.O.A.F. y Cuenta de PP&GG)
• Status y grado de avance temporal (Cronograma)
• Status y grado de avance de costes (Presupuesto)
• Riesgos principales y problemática central
• Continua actualización de elementos clave que requieren la atención directa del Portfolio
Board:
• Acciones autorizadas por el Comité

51
• Incidencias y riesgos de alto nivel (“Portfolio level”)
• Presupuestos y Gastos
• Road-maps e hitos críticos (“Portfolio level”)
• Requerimientos de cambio de alto nivel (“Portfolio Change Requests”)

IV. ASPECTOS COMPLEMENTARIOS La P.M.O. será “contact point” para aquellos que:
• Requieran información sobre el Comité o el Portfolio
• Tengan necesidades de negocio relacionadas con el Portfolio
• Quieran notificar al Portfolio Board problemas o incidencias con cualquier componente de
cualquier Programa del Portfolio

El Papel de la P.M.O.
CoE, Centre of Excellence (U.K.)
(El “Centro de Excelencia”, contexto británico)

Recientemente, dentro del sector público británico, se viene asentando una figura singular
u original de P.M.O. orientada a la excelencia y mejora continua en materia de Project/
Programme Management dentro de la Organización. Se trata del “Centro de Excelencia”,
cuya presencia ha adquirido especial relevancia en Reino Unido por su papel clave en la
organización y gestión del Programa de los Juegos Olímpicos de Londres 2.012.
Este tipo de P.M.O. ofrece los servicios básicos, más los servicios adicionales de nivel 1, nivel
2 (consultancy&advisory) y nivel 3 (strategic & governance services).
El CoE es responsable de asegurar:
1. La selección adecuada de Proyectos y Programas
2. La ejecución eficaz de ambos

Para su implantación exitosa, el CoE debe contar con plena autoridad, es decir, una
transferencia total de poder y presupuesto desde las unidades de negocio.

RESPONSABILIDADES CENTRALES DEL CoE

- CAPACITACIÓN Y DESARROLLO DE PROJECT Y PROGRAMME MANAGERS

Responsabilidad transferida desde:

• Departamento o Área Funcional de Recursos Humanos
• Unidad de Gestión del Talento
• ACUERDO SOBRE LOS OBJETIVOS FIJADOS PARA CADA UNO DE LOS PROJECT Y
PROGRAMME MANAGERS

Responsabilidad transferida desde:

• Departamento o Área Funcional de Recursos Humanos
• Unidad de negocio a la que pertenece el manager
 - ESTABLECIMIENTO DE ESTÁNDARES Y SU AUDITORÍA

Responsabilidad transferida desde:

• Departamento de Calidad (QA) de la Organización
• ASIGACIÓN DE PERSONAL CLAVE (PROJECT y PROGRAMME MANAGERS)

Responsabilidad transferida desde:

• Unidad de negocio (“line-of-business unit”)

3.4.5. Conclusiones
Antes de cerrar de forma definitiva este apartado relativo al “papel de la P.M.O.”, hay lugar para
ciertas reflexiones de valor:

• Las Oficinas de Gestión del Portfolio, Programa y Proyecto (P.M.O.s) merecen una simpatía
por su papel clave en dentro de la Organización en la que operan.

• Muchas veces las P.M.O.s son percibidas como:

Fuerza “policial” de comprobación y control, no bienvenida por Project Managers

….PERO SON UN

Soporte deseado por Project Managers en la gestión de Proyectos

• Es justo reconocer su relevancia dentro de la Compañía, por funciones tan críticas como: El
desarrollo de Equipos de Proyecto (Project Management Teams)

El asesoramiento en la Selección y Priorización de Proyectos

• GAP

Con las tres opiniones anteriores se puede concluir que en aquellas Empresas donde se ha
implementado y está operativa, con más o menos éxito, una P.M.O., se da un desequilibrio (“gap”)
entre las expectativas de los Project y Programme Managers que operan bajo el paraguas de
la P.M.O. y los servicios asignados a la propia P.M.O. (de conocimiento para el conjunto de la
Organización a través del Portfolio Charter).

No siempre coincide aquello que los Gerentes de Proyecto (y Programa deberíamos añadir)
esperan de la P.M.O. con sus atribuciones finales, respaldadas desde Senior Management
(Nivel Ejecutivo de la Organización).

Hoy supone todo un reto implementar nuevas P.M.O.s y reconducir aquellas existentes –
que lo requieran-, de forma que dicho “gap” o desequilibrio sea subsanado, consiguiendo
una armonización plena de las Operaciones –por Proyectos, Programas y Portfolio- de la
Organización.

53
3.5. El tamaño importa
La implantación de la P.M.O. dentro de una Organización existente supone todo un reto de
alcance corporativo ya que se trata de un GRAN CAMBIO ORGANIZACIONAL.

La implantación requiere de unos pasos previos (fase de estudio, análisis, concepción, diseño
y planificación de la implantación) que incluye la preparación del “Business Case” o “Caso de
Negocio” del propio Proyecto de Implantación de la P.M.O. con el que se demuestre que los
beneficios derivados de su implantación superarán los costes de la misma. Unos costes de
implantación que serán siempre proporcionales al tamaño con el que se diseña la P.M.O.

El estudio ya mencionado previamente de ProgM (Programme Management Special Interest

Group, Association for Project Management – A.P.M.) conocido como “PMOs and Portfolio
Management – What Leads to Success” (Paul Rayner, Project Magazine, Enero 2.010),
demuestra que:

• La dimensión de las PMOs varía enormemente entre Organizaciones.

• El factor único que parece determinar el tamaño de la PMO es el ALCANCE de los

SERVICIOS provistos (ver gráfico adjunto).

• La “Oficina de Proyecto” o “Project Office” (≠PMO) gestiona un (1) Proyecto, integrando a

una media de 3,50 empleados como staff propio de dicha oficina.

• Las P.M.O.s que gestionan Programas cuentan con un promedio de 8,30 empleados.

• Las P.M.O.s que gestionan Portfolio tienen una media de 10,70 empleados.

• Un porcentaje significativo de estos promedios de empleados son empleados de “perfil

administrativo” que aminora el coste de dotación de staff de las P.M.O.s.

Resultados del Estudio de ProgM (APM) - Junio/ Julio 2009 “¿Qué dimensión tiene su
P.M.O.?”
Profundizando en el estudio mencionado de ProgM (Programme Management Special Interest
Group, Association for Project Management – A.P.M.), en base a la campaña de investigación
efectuada entre junio y julio de 2.009, se alcanzan conclusiones de gran valor para la
caracterización de la P.M.O. actual:

• Las P.M.O.s que gestionan Portfolios (carteras de Proyectos) pueden llegar a alcanzar un
staff o plantilla (recursos humanos propios) de hasta 50 personas.

• Aquellas P.M.O.s de todavía mayor envergadura (fundamentalmente los proveedores

globales del sector de las nuevas tecnologías) pueden alcanzar hasta 2.000 personas (en
muchas ocasiones se escoge el término “Centre of Excellence”, CoE)

• Otros factores detectados que determinan la dimensión de la P.M.O. son:

►► La diversidad y complejidad de los servicios provistos

►► Los objetivos generales establecidos por la Organización para la P.M.O.:

Cuanto mayores son las expectativas, mayores los recursos necesitados

• El marco de financiación de la P.M.O.:

►► Corporate overheads (costes operativos no vinculados con la producción)

La actividad de una P.M.O. supone, para el conjunto de la Organización, una serie de

gastos o costes operativos no vinculados con la actividad productiva de la Compañía,
precisamente aquella que genera valor (sobre todo económico) para la misma.

Este hecho despierta, tradicionalmente, el recelo y un continuo escrutinio por parte del
Departamento de Control Financiero y de Contabilidad, quien vigilará la justificación del
coste de la P.M.O., es decir, si su gasto corriente trae un retorno económico cuantificable
positivo para la Organización, traducible en los indicadores financieros de la Compañía:

1. facturación,
2. margen sobre ventas,
3. costes fijos y variables,
4. E.B.I.T.D.A., etc.

►► Por Proyectos individuales

En este caso, si la Organización decide que así sea el marco de financiación de la

P.M.O., ésta financiará su actividad por Proyectos, precisamente aquellos que han sido
“validados” o aprobados junto con Senior Management.

►► Por Programas individuales

Es la modalidad de financiación alternativa a la anterior en la que la asignación

presupuestaria de la P.M.O. se hace según los Programas que maneja, gestiona o de
los que es responsable ante Senior Management.

55
• Es fundamental entender y asimilar el Contexto de la Organización a la hora de implantar
una P.M.O., ya que dicha implantación es todo un Programa de Cambio Organizativo que
supone un reto para la Compañía por el tiempo y esfuerzo dedicado en Comunicación
Interna, un aspecto crítico muchas veces obviado por las Organizaciones y que está en la
raíz de un elevado número de fracasos en la implantación de la P.M.O.

Es el momento de pasar a analizar la ESTRUCTURA de la P.M.O., de la que cabe resaltar dos

pinceladas fundamentales:

• La tipología de estructura escogida determina los recursos de la PMO.

• La PMO puede operar en varios niveles, de forma que la labor de gestión fluye desde la
PMO central (también llamada “P.M.O. Corporativa”) hacia múltiples P.M.O.s en niveles
inferiores (“P.M.O. nivel Portfolio”, “P.M.O. nivel Programa”, “P.M.O. nivel Departamental/
Área/División”, “P.M.O. de Proyectos”, etc.). Es lo que se denomina como “P.M.O. dispersa”.
En el ejemplo de la figura inferior se presenta un modelo de “P.M.O. dispersa” de forma
que la estructura de la misma se encuentra distribuida por todos los niveles organizativos
de la Compañía.
C-Level Management hace referencia a la Presidencia de la Compañía, la que tiene la
última decisión, y que además apoya y patrocina inicialmente el Programa de Cambio
Organizativo que supone implantar una P.M.O.

La “P.M.O. corporativa” es co-reponsable de la direccióncorporativa de la

Organizaciónjuntocon el Nivel Sénior de la Compañía (Director General, Controller
Financiero), asegurando una traducción de la “Dirección Estratégica” de la Compañía en una
“Dirección por Objetivos”, es decir, “Dirección Estratégica POR Proyectos” (Organizaciones
“multiProyecto”, “proyetizadas”).

Bajo la “P.M.O. Corporativa” se localizarían P.M.O.s en los niveles inferiores de: Portfolio,
Programa y Proyecto.
En la página siguiente se presenta un ejemplo de estrutura de “P.M.O dispersa” sobre la que
ha trabajado el docente,

Estructura Organizativa en torno a la P.M.O. en una empresa de Ingeniería De Consulta

ANÁLISIS DEL EJEMPLO DE ESTRUCTURA ORGANIZATIVA EN TORNO A LA P.M.O.

El Organigrama mostrado (“P.M.O. estructura dispersa”), si bien representa una gran empresa
(sector: Ingeniería de Consulta), da una gran flexibilidad a la Organización, ya que:

Permite que distintas Áreas usen diversas metodologías, procesos o procedimientos, dando
soporte, a la vez, a Proyectos complejos y de gran envergadura

De cualquier forma, es inevitable cierta duplicación de esfuerzos y uso de recursos.

57
Por lo tanto, la “estructura dispersa” requiere más staff que una estructura “P.M.O. centralizada”

• La “P.M.O. Corporativa” prioriza y controla iniciativas de Inversión (Portfolio, Programa y

Proyecto).
• Las tres (3) P.M.O.s subordinadas son responsables de la supervisión y control de tres (3)
“sub-Portfolios”. Se trata de las P.M.O.s de “nivel departamental” (“Consulting Engineering”
–“Ingeniería de Consulta”-, “Research”–Investigación, Desarrollo e Innovación ó I+D+i- y
“Operations” –“Operaciones”-)
• El Departamento de “Consulting Engineering” es responsable de la gestión de dos
programas, “A” y “B”, cada uno dirigido, a su vez, por una P.M.O. de “nivel Programa” que se
encarga de dar soporte al Programme Manager a cargo del manejo de un Programa único.
• El Programa “A” es de mayor envergadura, escala o complejidad que el Programa “B”, por lo
que, tal y como se aprecia en la figura, el Programa “A” comanda a tres (3) Project Offices
u Oficinas de Proyecto, cada una de ellas responsable de la gestión de un Proyecto único,
liderado a su vez por un Project Manager.
• Los sub-Portfolios de los departamentos “Research” y “Operations” consisten en tres (3)
Proyectos (cada uno gestionado por una “Project Office” u “Oficina de Proyecto”) que no
requieren de una P.M.O. de “nivel Programa”.
• A nivel corporativo hay un “Programa de Cambio” dirigido por una P.M.O. de “nivel Programa”.
• Ciertos “key Projects” (“Proyectos clave” para la Organización) son coordinados por sus
respectivas P.M.O.

Una adecuada evaluación de los Requerimientos de staff de la P.M.O. resulta un FACTOR

CLAVE a la hora de implementar una P.M.O. en el sector de las nuevas tecnologías.

En el gráfico adjunto se contemplan los aspectos centrales considerados en la implementación

de una P.M.O. en el sector de las nuevas tecnologías.

Es fundamental destacar la necesidad

de proceder, cuando se concibe una
P.M.O. –no sólo en el sector de las I.T.s,
sino en cualquier sector o industria-, a
la correcta definición del componente
3º “Processes, Procedures and
Tools” (“Procesos, Procedimientos y
Herramientas”) de los que dispondrá la
P.M.O. –tienen consideración de “A.P.O.,
activos propios de la Organización”- y
que supondrán toda una mejora en la
productividad del PMO staff; una mejora
que se pretende se traslade al conjunto
de las operaciones de la Compañía.

Es por ello que la implantación de la

P.M.O. en una Organización (todo un
Programa de Cambio Organizativo)
 PERO, esto no ocurre siempre así (el componente 3º “Processes, Procedures and Tools” no es
bien definido), reduciendo entonces la eficiencia de la P.M.O. una vez ya implantada (excesivo
uso de recursos para escaso valor añadido = elevado coste operativo de la P.M.O., para un
reducido retorno al conjunto de la Organización).

Es fundamental, cuando se realiza el diseño organizativo de la P.M.O., la DISTINCIÓN entre:

Staff de PMO “nivel Portfolio”, que tiene un mayor grado de sofisticación (“Business Case Review
–“Revisión del Caso de Negocio”- y “Board of Directors Advise –“Asesoramiento al Comité
Ejecutivo de la Compañía”-). Se trata de un staff de larga duración, que supone una contratación
permanente de personal (elevado coste).

versus

Staff de PMO nivel Programa o Proyecto, con un claro menor grado de sofisticación (“administrative
support services”/”servicios de soporte administrativo” – perfil “Project Office” u “Oficina de
Proyecto”), que tiene una dotación de staff de menor duración, con un perfil de contratación
temporal (coste sensiblemente menor).

El análisis actual de la EMPRESA EN CRISIS (continuamente en crisis tras el “crack” de 2.008)

trae como consecuencia una conclusión inmediata: en las Empresas en situación difícil, el
foco de atención (la “línea de fuego”) se pone en dos elementos, (1) el “training” (gasto en
capacitación para el desarrollo de conocimiento, habilidades y competencias), y, (2) la P.M.O.
(sólo para aquellas que ya la tienen implantada, lógicamente).

A continuación se presenta un gráfico con el DIAGRAMA del CICLO de VIDA de la típica P.M.O.
“Nivel Portfolio”.

59
 El docente, D. Ivan Zamarrón Mieza, fruto de su experiencia profesional, reocmienda la siguiente
regla práctica para la determinación de número de personas o dotaicón de staff de una P.M.O.;

recursos_proyectos (personas)
Número de personas P.M.O. = +1
100

3.6. Grado de madurez de la P.M.O.

A pesar del gran interés despertado por las P.M.O.s dentro del ecosistema del “Project
Management”, a escala internacional, son pocos los casos de P.M.O.s que hayan resultado
exitosos, particularmente cuando se trata de implementar una P.M.O. de “nivel Portfolio”.

De hecho, en el estudio de International Consultants E.S.I. “The Global State of the PMO in
2011: Its Value, Effectiveness and Role as the Hub of Training” se concluía que:

Sólo el 17% de las Organizaciones veían a la P.M.O. “por completo eficaz a la hora de
afrontar los auténticos retos de negocio”.

Hasta el 30% de las P.M.O.s habían “sido cuestionadas en tiempos recientes”

Otros estudios, como por ejemplo, “The Reality of Project Management Offices ”, realizado por
B.Hobbes, de la University of Montreal en 2.006; ya había concluido que:

“La vida de la P.M.O. es muy reducida, la mayoría de los casos no supera los tres (3)
primeros años de vida”

• Senior Management hace autocrítica y comprueba que la calidad de su gestión de

proyectos es insatisfactoria (incumplimiento de alcance, tiempo, coste, calidad, etc.).
Se reflexiona sobre una solución: “la implantación de la P.M.O.!”

• Se nombra a un PMO Manager, quien lleno de energía, inicia la implementación.

• La inevitable “obsesión por le ajuste de costes” lleva a que el Área Financiera

centre su atención en los “administrative overheads” (nunca apoyados desde Senior
Management). La P.M.O. cae en esta categoría, siendo objeto de una “auditoría”
continua. Con una P.M.O. “junior”, escasean los “beneficios tangibles” (cuantificables,
con impacto positivo en los K.P.I del “cuadro de mando”). Además, el nivel ejecutivo
de la compañía, inicialmente centrado en “sus” programas y proyectos, ahora dirige
su atención a otros puntos del negico. Aunque el coste de iimplantar la P.M.O. es una
fracción muy reducida del valor del portfolio o programa que supervisa y controla,
si no puede demostrar la consecución de objetivos de negocio, se vuelve vulnerable
dentro de la Organización.

• Rápidamente la P.M.O. es obligada a ajustar suscostes de estructura, liberando staff.

Aún así, la P.M.O. continúa operando, pero con menos personal es incapaz de cumplir
sus objetivos, reculando hacia una actividad de soporte administrativo.

• El valor de la P.M.O. es de nuevo cuestionado. Senior Management decide que el

soporte administrativo de la P.M.O. es todo un lujo para la Organización. La P.M.O es
eliminada.
 ...2 AÑOS DESPUÉS = Senior Management observará que la gestión de proyectos no es
satisfactoria y empezará otro ciclo.

A continuación se muestra un GRÁFICO EVOLUTIVO DEL GRADO DE MADUREZ DE LA P.M.O.

(aplicable a cualquier tipología de P.M.O.)

OBJETIVO: UNA P.M.O. madura que aporta
VALOR a la Organización (“beneficios
tangibles”) y puede probarlo (cuantificación
del éxito = Balance Score Card / K.P.I.)
Ciclo de Maduración es aplicable a cualquier
P.M.O.:
• Nivel Corporativo (Portfolio)
• Nivel Departamental

• Nivel Programa

La idiosincrasia de la vida corporativa hace difícil alcanzar los niveles 4 y 5.

Fundamental = apoyo/patrocinio constante de Senior Management.

61
3.7. El éxito de una P. M. O.
Existen 9 ASPECTOS CLAVE para el éxito de una P.M.O. Son los siguientes:

1. AJUSTE A LAS NECESIDADES DE LA ORGANIZACIÓN

2. SERVICIO SOPORTE A PROGRAMME & PROJECT MANAGERS

3. BENEFICIOS TANGIBLES PARA LA ORGANIZACIÓN

4. ASEGURAR EL APOYO DEL NIVEL EJECUTIVO

5. UNA VISIÓN CLARA

6. VALOR AÑADIDO DEMOSTRADO

7. AYUDA, SOPORTE A SENIOR MANAGEMENT (ADVISORY&CONSULTANCY)

8. ELEMENTO DE ENLACE PARA EL CONJUNTO DE LA ORGANIZACIÓN

9. EXITOSA IMPLEMENTACIÓN DE LA P.M.O.

A continuación son desarrollados todos y cada uno de los factores de éxito.

FACTOR DE ÉXITO Nº1: “Ajuste a las necesidades de la Organización”

• Toda Organización = “sello único” en estructura, cultura y terna “misión, visión y valores”

• Éxito P.M.O. = armonización “sello único” & “objetivos de negocio”

• La P.M.O. debe colaborar en la Gobernanza*** de toda la Organización:

►► Fomentando iniciativas adecuadas que generen beneficio (cuantificable)

►► Desaconsejando o evitando iniciativas no alineadas con los objetivos organizativos y de

negocio

*** Gobernanza: responsabilidad de Senior Management, afecta al conjunto de la

Organización. Crea un marco para la toma de decisiones de gestión lógica, consistente
y repetible. La P.M.O. trabaja en la “Gobernanza de Portfolio y Programa”.

FACTOR DE ÉXITO Nº2: “Servicio soporte a Programme & Project Managers”

La P.M.O. debe facilitar soporte eficaz y práctico a Project / Programme Managers, liberándoles
de las tareas rutinarias, de forma que, puedan concentrarse en el éxito de la gestión del
Proyecto/Programa del que son responsables, respectivamente.

Una buena práctica que facilita el éxito en la gestión de Programas o Proyectos es que:

“el 90% de la carga de trabajo (workload) del Programme o Project Manager esté
destinado a la COMUNICACIÓN”
Difícilmente un Programme / Project Manager podrá centrar sus esfuerzos en el área de
Comunicación si desperdicia su tiempo en:

• Administración
• Contabilidad
• Producción de informes

FACTOR DE ÉXITO Nº3: “Beneficios tangibles para la Organización”

Los beneficios tangibles (cuantificables, demostrables) derivados de la implantación de la
P.M.O. son demandados ya en los primeros pasos de la propia P.M.O.
Es recomendable entonces:
• Establecer un set de directrices ajustadas a la Organización, como es el caso de:

Ejemplos

Templates = “Activos Propios de la Organización”

Procesos

• Ayudar a Programme/Project Managers a cumplir con estándares y buenas prácticas

internacionales.
• Los nuevos procesos introducidos deben estar alineados con los ya existentes que
aportan valor a la Organización.

FACTOR DE ÉXITO Nº4: “Asegurar el apoyo del nivel ejecutivo”

La P.M.O. tiene dos (2) formas clave de aportar valor a la Organización:
1. Descartando Programas y Proyectos que no generan beneficio
2. Ayudando a la Organización a ejecutar su Estrategia

PERO, no siempre dichas acciones de la P.M.O. son bienvenidas dentro de la Organización, lo

que conlleva a la aparición (en etapas no tardías del ciclo de vida de la P.M.O.) de una fuerte
“OPOSICIÓN POLÍTICA” por parte de:
1. Programme / Project Sponsors
2. Otros Stakeholders influyentes

FACTOR DE ÉXITO Nº5: “Una visión clara”

Para superar estas dificultades, la P.M.O. debe contar con el APOYO DEL NIVEL EJECUTIVO
desde el inicio, cuando su implantación es patrocinada, y, sobre todo, en los momentos
en que la P.M.O. pierde credibilidad o su aportación (de valor) a la Organización está en
entredicho.

63
La propia P.M.O. debe ser proactiva desde el comienzo de su implantación para mostrar cómo
va a apoyar al conjunto de la Organización. Es una herramienta eficaz para ganar el APOYO
EJECUTIVO en todo momento.

FACTOR DE ÉXITO Nº6: “Valor Añadido Demostrado”

• La P.M.O. debe demostrar de forma continuada el valor generado que genera para la
Organización.
• La P.M.O. debe establecer métricas apropiadas para la cuantificación del valor generado:

►► Nivel de éxito de Programas y Proyectos, indicadores:

- Coste de Capital
- Plazos
- Costes Operativos
- Beneficios tangibles conseguidos

►► Mejora en el equilibrio de la Gestión del Portfolio, factores:

- Riesgo
- Etapas del Ciclo de Vida del Proyecto o Programa

►► Alineamiento Estratégico y Tipo de Inversión

►► Mejora en la contribución a los objetivos estratégicos

• Toda P.M.O. de nueva implantación se realizará, al inicio, la siguiente pregunta: “¿QUÉ

REFERENCIA (baseline) TOMAR PARA CUANTIFICAR EL VALOR GENERADO POR LA
P.M.O.?”
• Investigar el grado de satisfacción de los siguientes agentes en las condiciones actuales:

►► Programme & Project Managers

►► Sponsors

►► End users

►► Resto de Stakeholders

• Para ello se recomienda la realización de campañas investigativas cada 6 meses para:

►► Comprobación de mejoras significativas

►► Evitar la ardua tarea de recopilación y procesamiento de:

- Datos complejos

- Progreso estratégico
• La Organización no debe perder nunca de vista una fuente crítica de valor de negocio:

LA MEJORA EN EL EQUILIBRIO DEL PORTFOLIO GESTIONADO (aplicable a P.M.O.s de

“nivel estratégico” o “corporativa” y la de “nivel Portfolio”)

• Existen dos formas de mejorar el equilibrio del Portfolio:

1. Apropiado Mix de Programas&Proyectos alineados con la Estrategia de la Organización

2. No lanzamiento simultáneo de Programas&Proyectos similares, por distintos

departamentos de la Organización (duplicación de resultados = uso inefectivo de recursos)

• ¿Cómo facilitar el equilibrio en la gestión del Portfolio? Dos formas:

1. Claridad en torno a los beneficios de cada Programa y Proyecto

2. Interrupción (en fase de Iniciación) de Programas y Proyectos de escaso valor:

- Fortalecimiento del papel jugado por el CASO DE NEGOCIO

- Implementación de un PROCESO FORMAL DE APROBACIÓN

FACTOR DE ÉXITO Nº7: “Ayuda, soporte a Senior Management (Advisory & Consultancy)”

La P.M.O. debe facilitar una INFORMACIÓN CLARA, FIABLE, DETALLADA Y FÁCILMENTE

COMPRENSIBLE que ayude a

Senior Management en el proceso de TOMA DE DECISIONES.

La herramienta habitual que para ese fin utiliza la P.M.O. es el MANAGEMENT DASHBOARD,
una herramienta visual, que facilita la comprensión gráfica y Visión de Alto Nivel del ESTATUS
y GRADO DE AVANCE de PORTFOLIO, PROGRAMA y PROYECTO.

FACTOR DE ÉXITO Nº 8: “Elemento de enlace para el conjunto de la Organización”

La P.M.O. debe interactuar con un amplio rango de Stakeholders, con los que establecerá las
siguientes relaciones (poder, influencia, negociación,etc.):

65
FACTOR DE ÉXITO Nº9: “Exitosa implementación de la P.M.O.”

• Los tres (3) actores afectados por la implantación de la P.M.O. son:

1. Programme / Project Managers

2. Users & Stakeholders

3. Senior Management (“Decission Makers”)

• Por lo tanto, la implementación de la P.M.O. debe ser gestionada como un Programa de

Cambio Organizacional (Change Management), incluyendo aspectos centrales tales como:

►► Planificación (Planning)

►► Gestión de Interesados (Stakeholders Management)

►► Gestión de la Comunicaciones (Communications Management)

►► Justificación de Negocio (Benefit Management)

 • Cabe resaltar dos recomendaciones finales para el éxito en la Implementación de la P.M.O.:

►► Ejecución gradual de su implementación (“por pasos”, “stepped approach”)

►► Enfoque, en las etapas iniciales, en actividades con exposición directa y visibilidad

inmediata a Senior Management, por ejemplo, el Registro de Programas y Proyectos en
curso mostrando por vez primera la amplitud y alcance del Portfolio gestionado por la
P.M.O.

3.8. Conclusiones
La implantación de la P.M.O., fundamentalmente cuando se establece a “nivel Portfolio” o
“nivel Programa”, conlleva un alto impacto, de muy diversa índole (con implicaciones o afección
directa en costes, Operaciones, organigrama, desarrollo de negocio, etc.), en la Organización
que apuesta, desde el Nivel Ejecutivo, por su puesta en marcha.

La P.M.O. implantada disciplinará a dos actores fundamentales dentro de la propia Compañía:

SENIOR MANAGEMENT MIDDLE MANAGEMENT

Estableciendo un proceso Estableciendo un proceso

racional para la evaluación de
propuestas de nuevos proyectos
y Programas que aportan
beneficio a la Organización,
frustrando así a muchos
ejecutivos acostumbrados a
“abrirse camino a voces”
racional para la evaluación de
propuestas de nuevos proyectos
y Programas que aportan
beneficio a la Organización,
frustrando así a muchos
ejecutivos acostumbrados a
“abrirse camino a voces”

NICOLAS MAQUIAVELO
(1469-1527)
“Nada hay más dificultoso y
arriesgado de ejecutar, o más
incierto es su éxito, que tomar las
riendas en la introducción de un
nuevo estado u orden en las cosas.
El “reformador” gana, por un lado,
enemigos o detractores, aquellos
beneficiados por el antiguo orden.
Una tibieza que nace, a medias,
del miedo de los detractores y de
la incredulidad del Hombre, quien
no cree en nada nuevo hasta que
lo ha comprobado de primera
mano”.
(Traducción libre sobre
Machiavelli, N., The Prince,
penguin Books, London, UK
-2003)
Se ha insistido ya en el hecho de que
la implantación de una P.M.O. en una
Organización que no cuenta inicialmente
con ella supone, en realidad, acometer todo
un Programa de Cambio Organizacional
(Change Management).
Sin duda, las P.M.O.s pueden superar las
objeciones, críticas y recelos que en todo
momento despierta en actores interesados
–en su caída probablemente, por su pérdida
de poder en la toma de decisiones interna
de la Compañía-, y generar valor para la
Organización.
Es crítico remarcar que el coste de
implantar y operar una P.M.O. supone una
muy pequeña parte del valor del Portfolio,
Programas y Proyectos que supervisa.

67
9 Aspectos clave para el éxito de una P.M.O.

1. Ajuste a las necesidades de la Organización

2. Servicio soporte a Programme & Project Managers

3. Beneficios tangibles para la Organización

4. Asegurar el apoyo del nivel ejecutivo

5. Una visión clara

6. Valor añadido demostrado

7. Ayuda, soporte a Senior Management (Advisory& Consultancy)

8. Elemento de enlace para el conjunto de la Organización

9. Exitosa implementación de la P.M.O.

Dirección de
proyectos MÓDULO II, BLOQUE I

• Andersen, E. S.; Grude, K. V.; Haug, T. (2004). Goal Directed

Project Management. Londres: Kogan Page.

• CSC (2003). Improving the Performance of Your Program

Bibliografía Management Office. Waltham: Computer Sciences
recomendada Corporation.

• Dinsmore, P. (ed.) (1993). The AMA Handbook of Project

Management. Nueva York: Amacom.

• Hanford, M. (2011). “Programs and Approaches: Are You

on the Right Track?”. Gartner

• Joana, J. M.; Gracia, R.; García, A. L.; Bolart, J. (2012).

Gestión con éxito de proyectos de transformación: El
caso ICS. Barcelona: Profit.

• Marchewka, J. (2003). Information Technology Project

Management: Providing Organisational Value. Hoboken :
John Wiley.

• McDonald, M. P. (2012). “McKinsey Report Highlights

Failure of Large Projects: why it is better to be small,
particularly in IT”.

• McKinsey (2012). “Delivering large-scale IT projects on

time, on budget, and on value”.

• Mieritz, L. (2012). “Survey Shows Why Project Fail”.

Gartner

• Mieritz, L.; Fitzgerald D. (2012). “ITScore for Program and

Portfolio Management”. Gartner

• Office of Government Commerce (2011). Managing

Successful Programs. Londres: The Stationery Office.

• Olson, D. L. (2004). Introduction to Information Systems

Project Management (2ª. ed.). Nueva York: McGraw Hill.

• Pinto, J. K. (2007). Project Management: Achieving

Competitive Advantage. Upper Saddle River: Pearson-
Prentice Hall.

69
 • Pinto, J. K. (1997). “Make Politics Work for You”. Research Technology Management (vol. 40, núm.
1, págs. 9-10).

• Pinto, J. K.; Millet, I. (1999). Successful Information System Implementation: The Human Side.
Project Management Institute.

• Project Management Institute (2006). The Standard for Program Management (2.ª ed.). Pensilvania:
Project Management Institute.

• Project Management Institute (2013). A Guide to the Project Management Body of Knowledge.
Fifth Edition. Pennsilvània: Project Management Institute.

• Thiry, M. (2010). Program Management. Farnham, Surrey: Gower Publishing.

MÓDULO II, BLOQUE Ii

Se recomiendan lecturas clave que permitirán, a todo alumno especialmente interesado en la P.M.O. y su
relevancia en el mundo de la Empresa, profundizar en lo estudiado en detalle en el bloque IV:

• Bolles, Dennis L.; Hubbard, Darrel G. (2012). A compendium of PMO case studies: Reflecting
Project Business Management Concepts. A validation of Project Business Management (PBM)
and the PBM Organization Model for Driving Business Benefits and Value. PBMconcepts.

• Price Perry, M. (2009). Business Driven PMO Setup: Practical Insights, Techniques and Case
Examples for Ensuring Success. J. Ross Publishing

• Nir, Michael (2013). The Agile PMO: Leading the Effective, Value driven, Project Management
Office (Volume 3). CreateSpace Independent Publishing Platform; 3 edition.

• Kerzner, Harold R. (2005). Using the Project Management Maturity Model: Strategic Planning for
Project Management. Wiley; 2 edition.

• Project Management Office (PMO): A Quest for Understanding (Final Research Report). Brian
Hobbs, Phd, MBA, PMP y Monique Aubry Phd, MPM

En la página siguiente se aportan las portadas de referencias bibliográficas, para facilitar al interesado
sus portadas en caso de interés en su adquisición en portales de Internet generalistas o especializados
en literatura de gestión y empresarial.
www.pbmconcepts.com www.barnesandnoble.com

71
EUDE EUROPEAN BUSINESS SCHOOL
C/Arturo Soria, 245 - Edificio EUDE
CP: 28033. Madrid, España.
Tel: + 34 91 593 15 45
e-mail: informacion@eude.es
www.eude.es
C/98 # 9A - 41 Oficina 204
Bogotá DC, Colombia.
Tel: + +57 163 524 97
e-mail: federico.ospina@eude.es