m02 Pmp-Dir Est Proebook
m02 Pmp-Dir Est Proebook
m02 Pmp-Dir Est Proebook
de proyectos
Objetivos
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
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
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”.
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.
“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.
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.
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,
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 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).
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.
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:
• Destacar los resultados derivados de las investigaciones y análisis realizados durante los
últimos tres meses.
• 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).
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):
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.
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)”.
• 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.
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:
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.
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).
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.
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.
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.
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).
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).
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.
(3) Gestión del tiempo o planificación Vendra determinada por el equipo y las
necesidades del cliente.
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:
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.
23
considerando su trabajo de gestión realizado: la promoción inmobiliaria entrega en plazo,
dentro de presupuesto y cumpliendo las especificaciones (Calidad) establecidas.
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:
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:
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:
i. Múltiples Proyectos.
iii. Beneficios.
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:
• 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.
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).
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 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.
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”).
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:
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.
A continuación se presentan cuatro (4) tipologías de Proyecto que se pueden identificar en las
empresas.
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.
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.
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 “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).
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).
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”.
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”).
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.
• Tareas administrativas.
• Manejo de la Información.
• Procesamiento de Datos.
33
(“Portfolio”) de Programas y Proyectos de gran complejidad, con un elevado número de
personas involucradas en su desarrollo.
• Necesidades de la Organización
• Complejidad
• Cantidad
• Tamaño
• Sofisticación
• Responsabilidades
• PROJECT OFFICE
(“Oficina de Proyecto”)
(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”).
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.
DE CONTROL
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.
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:
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:
1. Servicios centralizados.
2. Gestión y Dirección.
3. Mejora en la eficacia (resultados/objetivos) y eficiencia (optimización de recursos).
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”).
Los estudios actuales1 muestran que cerca de tres cuartas partes del total de Empresas
británicas (U.K.) implementan una P.M.O.
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”).
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:
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. Mejor soporte a los P.M. a través de técnicas, procedimientos, etc., en materia de project
management.
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:
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.
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.
41
Dicho esquema se caracteriza porque:
No debe perderse en ningún momento de vista el objetivo por el que se implementa una P.M.O.
en una Organización:
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
• 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.
3. http://www.pmsolutions.com/collateral/research/
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):
Curiosamente, un 25% respondió que todos los Proyectos de su Organización son dirigidos por
una P.M.O. ya implantada.
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:
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):
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.
0 Servicios básicos
1 Servicios adicionales
2 Servicios de asesoramiento y consultivos
3 Estrategia y gobernanza
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:
• 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.
• 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”):
• Project Managers
• Sponsors
• Contingencies (Riesgos)
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
A escala Portfolio, la P.M.O. centrará sus esfuerzos en tres vehículos de información clave:
• Cronograma
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.
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.
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.
….PERO SON UN
• 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)
• 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.
• 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.
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.
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.
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.
• 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.
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,
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
57
Por lo tanto, la “estructura dispersa” requiere más staff que una estructura “P.M.O. centralizada”
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).
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
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”.
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”
OBJETIVO: UNA P.M.O. madura que aporta Ciclo de Maduración es aplicable a cualquier
P.M.O.:
VALOR a la Organización (“beneficios
tangibles”) y puede probarlo (cuantificación • Nivel Corporativo (Portfolio)
del éxito = Balance Score Card / K.P.I.)
• Nivel Departamental
• Nivel Programa
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:
• Toda Organización = “sello único” en estructura, cultura y terna “misión, visión y valores”
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
Ejemplos
Procesos
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.
- Coste de Capital
- Plazos
- Costes Operativos
- Beneficios tangibles conseguidos
- Riesgo
- Etapas del Ciclo de Vida del Proyecto o Programa
►► Sponsors
►► End users
►► Resto de Stakeholders
- Datos complejos
- Progreso estratégico
• La Organización no debe perder nunca de vista una fuente crítica de valor de negocio:
FACTOR DE ÉXITO Nº7: “Ayuda, soporte a Senior Management (Advisory & Consultancy)”
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.
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.”
►► Planificación (Planning)
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.
NICOLAS MAQUIAVELO
(1469-1527) Se ha insistido ya en el hecho de que
la implantación de una P.M.O. en una
“Nada hay más dificultoso y Organización que no cuenta inicialmente
arriesgado de ejecutar, o más con ella supone, en realidad, acometer todo
incierto es su éxito, que tomar las un Programa de Cambio Organizacional
riendas en la introducción de un (Change Management).
nuevo estado u orden en las cosas.
El “reformador” gana, por un lado, Sin duda, las P.M.O.s pueden superar las
enemigos o detractores, aquellos objeciones, críticas y recelos que en todo
beneficiados por el antiguo orden. momento despierta en actores interesados
Una tibieza que nace, a medias, –en su caída probablemente, por su pérdida
del miedo de los detractores y de de poder en la toma de decisiones interna
la incredulidad del Hombre, quien de la Compañía-, y generar valor para la
no cree en nada nuevo hasta que Organización.
lo ha comprobado de primera
mano”. Es crítico remarcar que el coste de
(Traducción libre sobre implantar y operar una P.M.O. supone una
Machiavelli, N., The Prince, muy pequeña parte del valor del Portfolio,
penguin Books, London, UK Programas y Proyectos que supervisa.
-2003)
67
9 Aspectos clave para el éxito de una P.M.O.
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.
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 C/98 # 9A - 41 Oficina 204
CP: 28033. Madrid, España. Bogotá DC, Colombia.
Tel: + 34 91 593 15 45 Tel: + +57 163 524 97
e-mail: informacion@eude.es e-mail: federico.ospina@eude.es
www.eude.es