Métricas útiles en una PMO ágil

Tiempo aproximado: 12 min.

Como ya contaba hace algunas semanas en mi artículo de despedida de BBVA, mi trabajo en el último año ha estado más cerca de una PMO que de lo que solemos conocer por Agile coaching. ¿Quieres conocer alguna de las métricas que utilizamos para dirigir nuestro trabajo? Sigue leyendo. 😉

Pero antes, ¿qué es una PMO y para qué sirve?

Comencemos por explicar para qué sirve una PMO. Voy a intentar hacerlo de tal manera que te sirva independientemente del tamaño de la organización para la que trabajes.

En la gestión de cualquier organización encontramos estas dos funciones:

  • la planificación estratégica, es decir, las decisiones que indican a todos hacia dónde vamos como organización, en el largo plazo,
  • y la planificación operativa, es decir, las decisiones sobre cómo distribuimos nuestros esfuerzos, en el corto y medio plazo.

Cuando la empresa es muy grande, estas dos funciones las suelen desarrollar dos equipos separados: el equipo de dirección y el equipo de gestión del portfolio. Incluso podemos llegar a ver que ambos equipos, a su vez, también se dividen en más equipos.

En este mismo contexto, grandes organizaciones, es frecuente ver equipos especializados en definir los procesos a seguir (o metodologías) para que todos los actores puedan hacer su trabajo de la mejor manera posible. Estos equipos son las Oficinas de Gestión de Proyectos —o en inglés Project Management Office (PMO)—. Gracias a ellas es posible tener una visión centralizada de toda la cartera (portfolio) de proyectos.

De todos modos, en empresas más pequeñas es perfectamente posible que se mezclen todas estas funciones. A veces, nuestro trabajo consiste en proponer cambios en la manera de realizar cualquiera de ellas.

En el artículo dedicado a la planificación estratégica adaptativa compartí este diagrama donde trataba de resumir varios de estos conceptos.

El equipo de dirección suele planificar la estrategia en base a objetivos medibles, a los que hacer seguimiento mediante algún tipo de cuadro de mando, y delega en el equipo de gestión del portfolio para que se encargue de determinar en qué productos o proyectos se debe trabajar, en qué orden y por cuánto tiempo. Esto es, se encarga de encontrar la manera óptima de repartir los recursos para ajustarse a la estrategia. En ese mismo artículo contaba que, en el contexto adecuado, es posible descentralizar esta función.

En una organización jerárquica, que entiende que el trabajo puede ser definido por un equipo (los thinkers) y ejecutado por otro (los doers) sin perjuicio para la eficacia de los resultados, una PMO básicamente se encarga de asegurar que los procedimientos son seguidos tal y como se han definido, de manera que la información y las decisiones se propaguen correctamente.

¿Y una PMO ágil?

En un contexto de negocios más volátil e incierto vemos que las organizaciones jerárquicas (que priman la eficacia sobre la innovación) tienen problemas para adaptarse. De ahí que el agilismo haya tenido tanto éxito, porque proporciona a las organizaciones esa adaptabilidad a los cambios frecuentes.

Ahora bien, Agile exige a las organizaciones un esfuerzo muy serio de transformación interna. Me gustan las tres leyes que enumera en su «The Age of Agile»:

  • Ley del Equipo Pequeño, los problemas grandes y complejos se resuelven «desescalándolos» en trozos pequeños y manejables,
  • Ley del Cliente, ya se dice en el Manifiesto Ágil que «nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor»,
  • Ley de la Red, todas las partes de la organización están continuamente explorando cómo añadir más valor a los clientes.

Cumplir con cada una de ellas requiere un esfuerzo muy serio por parte de todos; el impacto que puede tener una PMO en este cambio es enorme, dada su posición privilegiada para conectar, alinear y sugerir cambios a toda la organización. Así, una PMO ágil podría hacer lo mismo que una PMO tradicional, pero dejando de hacer todo aquello que en un contexto ágil es desperdicio y, especialmente durante una transición, ayudar a encontrar cuáles son los procesos, actividades, roles y artefactos más útiles para todos los actores involucrados.

De alguna manera podríamos decir que se trata de un equipo desarrollando un producto llamado «gestión del portfolio de proyectos». Lo cuál, como veremos más adelante, podría llevar a su propia desaparición.

¿Cómo medimos todo esto?

Creo que ya contó algo de esto en su charla en . Cuando esté publicado el video, lo enlazaré aquí.

Pero vayamos por partes. ¿Qué decisiones debe tomar el equipo que gestiona el portfolio de proyectos, que es el principal usuario de la PMO? A partir de la respuesta a esta pregunta podremos preguntarnos qué hay que medir, y consecuentemente cómo hacerlo.

Como hemos descrito antes, el equipo encargado del portfolio es una especie de intermediario entre lo que se quiere hacer (estrategia) y lo que realmente se hace (operaciones), y se asegura de que se produce la retroalimentación (feedback) necesarios. Por tanto, necesita:

  1. Entender la estrategia,
  2. Ayudar a adaptar esa misma estrategia dando feedback sobre la situación y los resultados de las decisiones tomadas,
  3. Indicar y/o recomendar qué hacer al resto de la organización para que se pueda ejecutar la estrategia,
  4. Conocer qué se está haciendo y qué se puede hacer como feedback para sus propias decisiones y recomendaciones.

Los dos primeros puntos son la relación entre el equipo de dirección y el equipo de gestión del portfolio. Los dos segundos son la relación entre el equipo de portfolio y el resto de la organización encargada de desarrollar los proyectos. En el gráfico de más arriba puedes identificar claramente las cuatro flechas.

Podríamos simplificar que la gestión de un portfolio consiste en decidir sobre las entradas, salidas y permanencias de los proyectos en el mismo. Algo así como:

  • Qué proyectos se deberían comenzar, es decir, cuáles son más apropiados para conseguir ejecutar la estrategia.
  • De esos, qué proyectos se pueden comenzar, es decir, para cuáles hay recursos suficientes (económicos y humanos). Sí, he dicho recursos humanos. 😉
  • Qué proyectos se deberían modificar o incluso detener, bien porque tenemos evidencia de que ya no aportan a la estrategia, bien porque de esa manera dejamos recursos disponibles para otros proyectos más deseables.

De lo que se deduce que, para gestionar el portfolio de proyectos, debemos tener:

  1. un criterio para priorizar los proyectos, es decir, para decidir a cuál favorecemos en un momento dado y a cuál no,
  2. un criterio para conocer los resultados de cada proyecto, en términos de su contribución real a la estrategia,
  3. artefactos y procesos que nos permitan aplicar y conocer el efecto de cada uno de estos criterios, por si fuera necesario cambiarlos.

En nuestro caso tuvimos algunas restricciones, en su mayoría provocadas por el gran tamaño de la organización y el contexto de exploración y transitoriedad que provoca estar inmerso en una profunda transformación de la organización. Los iré comentando a medida que sea oportuno. La restricción más seria era una cadencia trimestral en la que el equipo de gestión del portfolio estaba obligado a hacer seguimiento de todos los proyectos en curso (casi 200) para decidir si había que hacer algo o no con ellos, y además evaluar qué hacer con los nuevos proyectos que aparecían (que, afortunadamente para el equipo encargado, no eran muchos, pero que en realidad ocultaba un Lead Time bastante mejorable en mi opinión).

Priorizar los proyectos

El criterio que se usó para priorizar consistía en sumar los puntos que obtenía cada proyecto en función de las áreas estratégicas en las que actuaba. De esta manera se obtenía una lista ordenada de proyectos que permitía decidir sobre la asignación de los recursos necesarios, así como ayudar en la planificación conjunta, dando un criterio a los equipos que recibían peticiones de otros con el que priorizarlas en sus propias planificaciones.

Los que han trabajado últimamente conmigo saben que no soy amigo de elaborar listas de proyectos porque, entre otros efectos perversos, simplifican demasiado las conversaciones que debemos tener antes de favorecer a un proyecto frente a otros. Pero el hecho es que nuestra capacidad de influencia aquí era bastante reducida, además de que ya nos venía bien como punto de partida para conseguir poner de acuerdo a mucha gente.

El gráfico de arriba es un ranking de proyectos, es decir, una lista de todos los proyectos del portfolio, ordenados de más «valioso» a menos. En este gráfico hay cuatro colores, que se corresponden con las puntuaciones recibidas por cada proyecto en cuatro categorías diferentes. Los picos hacia abajo son valores negativos en esa categoría.

Luego veremos qué problemas trae esta manera de tratar el portfolio, pero asumamos que es una simplificación suficiente para lo que perseguimos.

El gráfico de abajo está formado por un diagrama de barras (azules) por cada proyecto (ordenados por su posición en el ranking) y representando el valor del presupuesto a destinar en el trimestre. La linea roja es el porcentaje acumulado del presupuesto.

Ahora imagina que te piden recortar el 25% del presupuesto. En principio podríamos pensar en recortar el 25% de cada proyecto en el portfolio, pero eso no siempre es viable, por lo que otra alternativa sería prescindir del 25% del presupuesto que nos resulta menos valioso. Las lineas punteadas verdes representan esa linea de corte. Todos aquellos proyectos que quedan detrás de la misma son los que (según nuestro ranking) menos valor van a aportar y, entre todos, usan el 25% del presupuesto total. Son nuestros candidatos a no recibir la asignación presupuestaria. Pero, ¿qué consecuencias tiene esto? Equipos que se quedan sin nada que hacer, proyectos a punto de acabar que se quedan sin dinero, etc.

Si retomamos la idea de recortar el presupuesto de alguno de los proyectos para que pudieramos hacer más, yo empezaría por ver qué pasa con esos picos en el gráfico de abajo. Cada vez que bajo uno de esos picos (recortando su presupuesto) estoy dándole la oportunidad a otro de aumentar el suyo o de incluir a un proyecto más por delante del corte.

Una manera de resolver todo esto sería incluir en nuestro ranking variables como el Coste de Retraso, que den la relevancia necesaria a aquellos proyectos pequeños y centrados en las necesidades de los clientes (recuerda, Ley del Equipo Pequeño y Ley del Cliente), pero aun así estaríamos todo el rato jugando a resolver el puzzle de intentar tener a todo el mundo ocupado. Ya he escrito hace tiempo sobre la eficacia en el uso de los recursos, pero podemos resumirlo en que tener a todo el mundo ocupado no es lo mejor que podemos hacer para conseguir los mejores resultados.

Otra mejora sobre este sistema de priorización consistiría en dejar de tratar a todos los proyectos como si tuvieran la misma naturaleza. Así, podríamos hablar de clases de servicio y aplicar políticas diferentes a cada una de ellas.

¿Y si no hubiera proyectos?

Y finalmente, la mejor de las optimizaciones sobre este modelo de priorización consistiría en que no hubiera proyectos sino productos, es decir, que el negocio estuviera repartido por equipos cuya misión consiste en cubrir una parte del negocio y, para ello, idea, desarrolla y explota todos los cambios necesarios. Empoderamos a los equipos para que ellos mismos decidan qué proyectos pueden y deben hacer. El portfolio, pues, queda distribuido y no se puede gestionar (dejar entrar proyectos, sacar prematuramente, etc) sino que hay que facilitarlo, guiarlo o «pastorearlo».

En este escenario surgen dos nuevas necesidades:

  • Hay que asegurarse de la coherencia entre lo que desarrollan diferentes equipos, pero eso es fácil de resolver cuando hay mucha conciencia de que se trabaja para el cliente (Ley del Cliente) y de que trabajamos en red (Ley de la Red), porque los propios equipos crean los mecanismos de coordinación necesarios. Sólo hay que empoderarlos y darle valor a la transparencia en toda la organización. La PMO puede habilitar y/o reforzar canales de comunicación para que esto suceda.
  • Hay que asegurarse de que la organización es capaz de adaptarse para usar mejor sus recursos. Aquí, el equipo de gestión del portfolio, gracias a su visión periférica a toda la organización, adoptaría de manera natural muchas de las funciones de la PMO y se dedicaría a aconsejar cambios sobre la propia organización de los equipos para lograr una mayor eficacia.

Nosotros, en nuestro intento de aprender de la organización para realizar esta tarea de asesoramiento, diseñamos los procesos de planificación conjunta (trimestral) con dos objetivos en mente:

  • que en el futuro se pudiera realizar algún experimento para comparar la planificación trimestral con otra cadencia diferente,
  • que las peticiones de trabajo a planificar entre diferentes equipos nos pudiera servir para sugerir cambios en la manera de organizar el trabajo y a los propios equipos.

Cambiar las cadencias

Para el primer objetivo lo tuvimos francamente difícil, especialmente porque la cadencia trimestral estaba impuesta «desde muy arriba». Hicimos varios intentos de representar el portfolio como un tablero Kanban pero la cadencia trimestral hacía poco práctico el esfuerzo. Pero habría estado genial conseguir la colaboración necesaria para medir la vida de los proyectos y representarlos en un tablero y unas gráficas como en la foto a continuación (tomada hace casi un año, cuando apenas sabíamos nada de la realidad del sistema con el que estabamos trabajando).

Cambiar la organización

Para el segundo objetivo creamos gráficos como el siguiente.

Con este tipo de gráficos constatamos que la planificación trimestral (que venía «heredada» de haber aplicado con más o menos éxito el concepto de PI Planning de SAFe en un contexto más reducido) estaba forzando a planificar juntos a equipos que tenían poco que ver entre ellos, salvo que solicitaban trabajos a unos terceros que eran muy transversales a toda la organización. Lejos de verlo como un obstáculo, nosotros lo tomamos como una oportunidad para transformar la organización y utilizamos los gráficos para explicar estas disfunciones.

Por ejemplo, imagina la situación hipotética de que algunos de los equipos transversales que reciben más peticiones de trabajos a planificar son UX o Arquitectura. Supón ahora que, indagando un poco, aprendes que la mayoría de esas peticiones en realidad se podrían resolver con mayor fluidez si en los equipos peticionarios (o muy cerca de ellos) hubiera perfiles especializados provenientes de estas dos disciplinas. Por tanto, una posible solución podría consistir en que se destinara, de manera estable, personal de sendos equipos transversales a dar servicio a esos equipos peticionarios. En consecuencia, estarías consiguiendo, desde la PMO, influir en la transformación de la organización desde unos silos a unos equipos multidisciplinares. Y esto es apenas un ejemplo de los muchísimos casos diferentes con los que nos podríamos encontrar.

Métricas de éxito

De todos modos, algo que tuvimos claro desde el principio es que nuestro trabajo estaría siempre orientado a satisfacer a los que consideramos nuestros usuarios: los equipos involucrados en la planificación conjunta. Otra cosa es que lo consiguieramos. :/

Para ello preguntamos al final de cada Planificación si los procesos y artefactos que habíamos diseñado e implementado les hacían trabajar mejor. Una especie de NPS. Aunque creo que, en ocasiones, el feedback está sobrevalorado, éste en particular nos fue útil para validar nuestras hipótesis acerca de la utilidad de lo que estábamos haciendo y, sobre todo, nos ayudaba a recordar nuestro propósito, que no era simplemente responder a una solicitud para implantar un proceso del que no sabíamos si era lo que la gente necesitaba o no.

Gran parte del éxito o fracaso de nuestro trabajo, sin embargo, tenía que ver con la comunicación. Uno de nuestros mayores retos fue conseguir captar la atención de todos los actores participantes. En una organización tan grande como BBVA España, las bandejas de correo de todo el mundo están siempre a rebosar. No es fácil conseguir un minuto de atención para una lectura pausada de un email con instrucciones. Asi que también desarrollamos estrategias para medir el éxito de nuestra comunicación. Creamos un site en el que publicamos todos los recursos necesarios para participar en el proceso de planificación conjunta y medimos cómo accedían a él.

También medimos la participación en nuestros artefactos (la mayoría Google Spreadsheets); menos usables que Jira, lo cuál le daba un plus de mérito a los que tenían la paciencia de usarlos y encima darnos feedback para mejorarlos. Una de nuestras métricas de éxito más importantes era el número de equipos que nos informaban de que tenían un plan viable para comenzar a trabajar en el nuevo trimestre. Al principio, el porcentaje era bajísimo, es decir, muy pocos veían algún valor en informar de que tenían su plan listo, así que tuvimos que acudir a los valores del grupo («Somos un solo equipo») y a la utilidad de saber que el proceso de planificación conjunta estaba funcionando para ellos. Sin embargo, gracias a nuestras métricas nos dimos cuenta de que todos esos esfuerzos eran en vano pues había una gran distancia comunicativa entre nosotros y los equipos, de manera que tuvimos que buscar alternativas. Enfocarnos en medir nos ayudó a tener evidencias empíricas de nuestras afirmaciones y, por tanto, a dar credibilidad a nuestras sugerencias y nuestras peticiones de ayuda.

En cualquier caso, la mejor métrica de éxito no es cuantitativa. En cierto modo, una PMO ágil es como un Agile coach porque, en mi opinión, cuando el resto de actores ya son capaces de decidir en base a evidencias y de medir el impacto de esas decisiones, entonces la PMO ya no es necesaria y debe desaparecer.

Hasta aquí la experiencia. Espero que te haya gustado y que me dejes ahí abajo (en los comentarios) alguna idea, sugerencia u opinión. Ya sabes que cualquier feedback es siempre bienvenido.


LA FOTO: Es la imagen de nuestro grupo de Whatsapp, justo después de que en la cola de la cafetería escuchara casualmente una conversación entre dos chavales (imagino que becarios) en la que uno definía su experiencia en la PMO como «pues me dedico a enviar correos a la gente diciéndoles lo que tienen que hacer».