Diferencia entre Programa y Portafolio

0

La gestión de proyectos está muy documentada. Hay mucha bibliografía y mucho conocimiento sobre el tema. Pero no pasa lo mismo con los programas y los portafolios (o carteras de proyectos). Si queremos subir un nivel y comenzar a gestionar múltiples proyectos, necesitamos conocer y poner en práctica la gestión de programas y portafolios. Pero la verdad es que aunque mucha gente usa estos términos, pocos conocen lo que significa. Se quedan con que son grupos de proyectos gestionados por la PMO. Los portafolios son grupos grandes y los programas grupos pequeños, y de ahí no pasan. Pero hay una gran diferencia de enfoque entre ambos conceptos. ¿Conoces la diferencia? Pues voy a intentar explicártela.

La gestión agrupada

Cuando lees libros y te formas sobre gestión de proyectos parece que el proyecto es un ente aislado en la organización. Parece como si nada más existiese y que los recursos asignados sólo se dedican a ese proyecto. Cuando comienzas a gestionar proyectos te das cuenta de que eso no es cierto. Los recursos rara vez son exclusivos. O bien, no conoces cuando entrarán en el proyecto, porque tienen que acabar otro antes, o bien están a tiempo parcial. En el mejor de los casos, sólo perderás recursos cuando suceda un problema en un sistema o aplicación en el que esa persona tiene un conocimiento clave. Pero es que además enseguida comienzas a ver dependencias con operaciones o con tareas de otros proyectos. Necesitas que te pongan en marcha un entorno de preproducción, o que la API contra la que vas a conectarte pase a producción.

Pero seguimos con una visión centrada en el proyecto, que se puede resumir en que el proyecto es un ente al que todo lo que tiene alrededor le molesta, le retrasa y le quita recursos.  Así que la primera reacción como jefes de proyecto, es la de buscar comunicación con los otros gestores. En proyectos gestionados con metodologías ágiles se crean figuras para este fin, como el scrum de scrums.

Cuando subes un poco, y comienzas a tener a tu cargo varios proyectos, con varios gestores de proyecto, ya no ves esas interdependencias como “molestias” entre proyectos, sino como relaciones. Esto pasa incluso más cuando hablamos de múltiples proyectos pequeños, ya que se multiplican las relaciones.  Así que no tardas mucho en darte cuenta del concepto de sinergia y valor añadido:

  • Sinergia: Cuando en dos proyectos se gestionan aspectos de forma conjunta se consiguen beneficios.
  • Valor añadido: La suma del valor de dos proyectos no es la suma, sino que hay un valor añadido.

Cuando ves esto has dado un gran paso como gestor, porque te das cuenta del valor que puedes aportar haciendo una gestión conjunta de esos proyectos. Puedes ahorrar costes y aportar más valor a la organización. Estamos a un paso de la gestión de programas y portafolios.

Sinergia entre proyectos

El primer concepto, la sinergia, es fácil de explicar. Consiste en tener una visión de todos los proyectos y detectar situaciones en las que haciendo una cosa de determinada manera podemos obtener un beneficio en todos los proyectos. Os pongo varios ejemplos:

  • Una modificación de alcance de un proyecto, puede suponer una mitigación de riesgo en otro.
  • Una reordenación o compartición de recursos puede aportar más valor a varios proyectos.
  • La reordenación de tareas en un proyecto puede aumentar la holgura en otro, sin aumento de coste.
  • La gestión de riesgos o interesados en varios proyectos puede ser común, ahorrando costes.

Valor agregado por múltiples proyectos

El segundo concepto, el de valor añadido, es más complicado de ver. Imaginemos que tenemos dos proyectos: uno es sobre integración con sistemas de anuncios on-line, y el otro es sobre la creación de una nueva web. Ambos proyectos tienen su business case, y ambos son rentables por separado. Se ha estimado que la integración con los anuncios on-line, producirá un aumento de ventas del 15%. La nueva web, más usable, permitirá una mayor conversión, proporcionando un aumento del 20% en ventas. Pero los analistas nos predicen que si tenemos ambos proyectos en marcha no esperaremos un aumento del 35%, sino del 55%. ¿Cómo es esto posible? Porque el valor que entregan los proyectos a las organizaciones no es lineal.

Otro ejemplo de esto sería que desde el área comercial nos dicen que hay:

  • 10% de clientes que se nos unirían si proporcionamos el servicio A
  • 20% de clientes que se nos unirían si proporcionamos el servicio B
  • 70% de clientes que se nos unirían si proporcionamos los servicios A y B integrados.

La mayoría de clientes no quieren el servicio A, que se conseguirá al acabar el proyecto A, si no tenemos el servicio B (con el proyecto B) también en cartera. Así hay un valor agregado importante de tener los dos proyectos.

Podemos encontrarnos con situaciones como:

  • Un proyecto no aportará valor a menos que otro se finalice. Ambos son independientes en su ejecución, pero si falta uno de los dos, no se podrá tener valor.
  • Dos proyectos en conjunto aportan más valor que por separado.
  • Dos proyectos en conjunto aportan menos valor que por separado (proyectos que colisionan estratégicamente).

Conocer esto nos permitirá mover recursos de un proyecto a otro, y enfocarnos en lo que más valor otorga a la empresa. Usando el ejemplo de los servicios A y B, es posible que el jefe de proyecto para conseguir el servicio B nos diga que no va a llegar a tiempo y que lleva una desviación de costes importantes. En ese momento, como gestor, no debes ver el proyecto B de forma aislada, sino conjunta. Así podrías tomar las siguientes decisiones:

  • Inyectar más recursos en el proyecto B, porque hay un ingreso importante asumiendo que A llegará a tiempo.
  • Restar recursos del proyecto A, porque si no llegamos a B, A aportará muy poco valor, y a lo mejor conviene ir más lento y enfocar los recursos en otro proyecto.
  • Mover recursos de A a B, de forma que se retrase el fin de A, pero se adelante el de B, de forma que adelantamos la fecha en la que tendremos los dos proyectos finalizados.
  • Evitar funcionalidades que implicarían goldplating, viendo que no aportan a la visión estratégica de conjunto.

Gestión de programas

Bueno, lector, ya te he soltado el rollo y te he descrito dos grupos de relaciones entre proyectos. Seguro que como eres una persona inteligente, ya estás adivinando por donde va esto de programas y portafolios.

Comenzamos por la gestión de programas y vamos a ver las definición de programas que vemos en PMI y en PRINCE2

Un programa es un grupo de proyectos relacionados, subprogramas 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.

Definición de Programa en el PMBOK

Un programa es una estructura de organización flexible temporal creada para coordinar, dirigir y supervisar la aplicación de un conjunto de proyectos y actividades relacionadas con el fin de obtener resultados y beneficios relacionas con objetivos estratégicos de la organización.

Definición de Programa según PRINCE2

Hay ligeras diferencias entre las definiciones, pero en la base ambas definiciones dicen lo mismo. Ambos hablan de gestionar un conjunto de proyectos relacionados para obtener beneficios. En la definición de PRINCE2 también se añade la temporalidad y objetivos de la organización, así como que también engloba actividades. Pero cuando profundizas en un programa según PMI ves que también es temporal, y que también habla de objetivos y beneficios comunes de la organización.

Aquí la clave es “relación”. Habla de proyectos relacionados. ¿Y qué entendemos por relacionados? Hablamos de proyectos que:

  • Comparten recursos o podrían compartirlos.
  • Tienen dependencias entre ellos.
  • Hay riesgos comunes
  • Hay interesados comunes

Hablamos de proyectos con elementos en común, y que, por lo tanto, pueden surgir sinergias en la gestión conjunta. Podemos definir un programa para gestionar varios proyectos cuando vemos que hay relaciones y posibles sinergias entre ellos. Muchas veces los programas, por eso de compartir recursos se focalizan en áreas funcionales de la organización, de forma que los proyectos dentro de ese área están dentro de un mismo programa. Otras veces, un producto o servicio, compuesto por muchas partes necesita de múltiples proyectos, relacionados entre ellos. Los resultados de un proyecto son las entradas del siguiente.

Bajándolo a una expresión fácil (y que por lo tanto resulta un poco inexacta), podríamos decir que varios proyectos podrían agruparse entre ellos como un programa, cuando los gestores de esos proyectos ven al resto como riesgos o molestias.

Así los objetivos, bajando un poquito de nivel, de la gestión de programas serán:

  • Coordinar y comunicar a los gestores de proyecto.
  • Detectar conflictos entre ellos y resolverlos.
  • Mitigar riesgos de las relaciones.
  • Detectar sinergias y aumentos de valor para explotarlas.
  • Detectar funciones o trabajos comunes que pudiesen centralizarse. Sospechosos habituales: Riesgos, Interesados y Planificaciones.
  • Revisar y proponer cambios a los cronogramas para maximizar la holgura conjunta y mitigar riesgos por dependencias entre proyectos.
  • Gestionar de forma conjunta los recursos del programa.
  • Abrir y cerrar el programa como el inicio y fin del conjunto de proyectos que engloba.

Gestión de portafolio

Sí, ya sé que has adivinado que lo del portafolio irá sobre el valor añadido, pero vamos a darle un poco de formalidad al artículo.

Igual que en el caso del programa, comenzamos con definiciones de portafolio:

Un portafolio es un conjunto de proyectos, programas, subportafolios y operaciones gestionados de forma conjunta con el objeto de alcanzar los objetivos estratégicos de la organización.

Definición según PMI

Un portafolio es el conjunto de todos los programas y proyectos independientes que están siendo llevados a cabo por una organización, un grupo de organizaciones o una unidad organizativa.

Definición según PRINCE2

De estas dos definiciones extraigo dos puntos clave:

  • No es necesaria la relación entre los proyectos.
  • Nivel de organización.

Es decir, es una agrupación de proyectos llevados a cabo por una organización. Normalmente una organización tendrá un portafolio de proyectos. Pero puede decidir tener más de uno si tiene dos grandes objetivos estratégicos y los proyectos no tienen nada que ver unos con otros.

Pero el punto clave es que no necesariamente deben estar relacionados. Es decir, podemos tener proyectos que “no se molestan” entre ellos.

Al hablar de objetivos de la organización, el enfoque aquí está en el valor que proporcionan estos proyectos, especialmente en el valor añadido por gestionarlos conjuntamente.

La gestión de portafolio suele ser trabajo de directores o responsables máximos de producto de la organización. Es más un trabajo estratégico. La gestión de portafolio está mas relacionada con gestión de inversiones que de proyectos. Hablamos de una gestión de muy alto nivel, normalmente relacionada con directores, directores generales, CEO, …

Los objetivos de una correcta gestión de portafolio de proyectos están relacionados con:

  • Determinar la estrategia de la organización, a partir de sus objetivos estratégicos.
  • Definir las líneas estratégicas a largo plazo, así como las inversiones esperadas.
  • Definir el conjunto de proyectos y programas a realizar, de forma que se maximice el valor entregado, frente a la inversión (ROI)
  • Seguir la evolución de proyectos, tomando decisiones sobre los mismos según su evolución, para maximizar el valor entregado.
  • Seguir los cambios del entorno, que puedan afectar a los objetivos estratégicos.
  • Adecuar el portafolio de proyectos a los cambios, creando proyectos, cancelándolos, modificándolos o reordenándolos.

Conclusión

Si has llegado hasta aquí verás que no tiene nada que ver la gestión de programas con la gestión de portafolio. Son dos mundos completamente diferentes.

¿Te siguen pareciendo simplemente agrupaciones de proyectos?

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios