Abusando de Scrum para Gestionar Portafolios de Proyectos

En este post quiero explicar como usar y adaptar los mecanismos de Scrum para la Gestión de Portafolios de Proyectos.

¿Qué es la Gestión de Portafolio de Proyectos?

La Gestión de Portafolio de Proyectos es una disciplina que incluye:

• La identificación, caracterización y evaluación de potenciales proyectos
• La definición y elección del mejor portafolio de proyectos para la organización
• El seguimiento del portafolio y de sus proyectos

Estas actividades suelen repetirse por ciclos de acuerdo al periodo en el cual está vigente un portafolio de proyectos. En general el calculo o definición del mejor portafolio de proyecto se basa en maximizar el valor cumulado por sus proyectos, en minimizar los riesgos generados por estos proyectos y en respetar restricciones que pueden ser por ejemplo presupuesto, capacidad de ciertas personas o sectores cuellos de botellas, dependencias entre proyectos, etc. Existen herramientas más o menos complejas para evaluar las numerosas posibles combinaciones de proyectos y identificar la más adecuada de acuerdo a valor, riesgo y restricciones.

La idea...

La idea fue aplicar los mecanismos de Scrum a la Gestión de Portafolio de Proyectos, con ciertas adaptaciones, para manejar los ciclos de portafolios de proyectos. Si bien no puede aplicarlo lo suficiente a mi gusto, pude probar la idea por parte en distintos contextos y me parece que amerita compartirla y seguir profundizando su uso. En un caso lo apliqué al nivel del Sector de Sistemas de una empresa del dominio financiero, y en otro caso al nivel de toda una empresa regional.

Scrum

¿Cómo se hace?

• Sprint: el sprint representa el periodo de tiempo durante el cuál está vigente un portafolio. En un contexto teníamos portafolios de proyectos vigentes por un mes, en otro caso duraba entre 3 y 5 meses. Los Sprints se siguen uno atrás del otro, cada vez con un nuevo portafolio de proyectos. 

• Artefactos:

• Backlog de Producto: el backlog es el inventario de todos los proyectos posibles. Cabe aclarar que incluye tanto los proyectos en curso como los sin iniciar o nuevos.

• Backlog de Sprint: es el portafolio de proyectos. Es un sub-conjunto del inventario de proyectos, optimizado de acuerdo al valor, riesgo y restricciones.

• Prácticas:

• Refinamiento del Backlog: es una parte esencial de la Gestión de Portafolio. Incluye las actividades siguientes:
• Identificar todos los posibles proyectos (por ejemplo relevando los distintos sectores involucrados).
• Filtrar con algún criterio (por ejemplo esfuerzo mínimo, duración mínima, complejidad, etc.) cuales realmente tienen entidad de proyecto.
• Registrarlos en el inventario de proyectos. 
• Caracterizarlos para precisar su alcance de alto nivel y los atributos que necesitamos en la optimización del portafolio: valor del proyecto, riesgo del proyecto, dependencias, estimaciones de alto nivel, presupuesto, etc.
• Actualizar el estado de los proyectos del inventario que ya están en curso (en particular para saber esfuerzo restante, fecha de fin, etc.)

• Planificación: a partir de los proyectos identificados y caracterizados en el inventario de proyectos, la idea es elegir la porción del inventario que va a entrar en el próximo portafolio de proyectos, de acuerdo a la optimización que mencionamos antes. 
• En particular suele ser útil contar con una herramienta para realizar esta optimización en base a valor, riesgos y restricciones , ya que suelen ser numerosas las combinaciones posibles de proyectos. 
• Luego es típico que un Comité de Portafolio pueda revisar el o los portafolios generados para elegir uno y/o forzar ciertos ajustes (bajar o subir algunos proyectos del portafolio). 
• Finalmente se publica el Portafolio generado y se difunde a quien corresponda.

• Reunión Diaria / Sincronización: la idea es tener reuniones periódicas para ir monitoreando el avance del portafolio, identificando acciones necesarias en caso de problemas a nivel de portafolio o de proyectos en particulares. En un caso se hacían quincenalmente y en otro caso mensualmente. Para eso se consolida información ejecutiva de los proyectos, como por ejemplo avances, próximos pasos, fecha estimada de fin, riesgos y problemas.

• Revisión: el objetivo es revisar al final del sprint como quedó el portafolio, comparar los resultados con las expectativas al inicio del sprint, revisar avances y ver que proyectos terminaron y cuales siguen en curso, detectar tendencias. Es útil explotar la información disponible y analizar datos como por ejemplo cantidad de proyectos por líder/sector, proyectos por estado, replanificaciones por proyecto, issues por proyecto, etc. Con la revisión se puede actualizar el inventario de proyectos, registrando los proyectos terminados, y el avance de los proyectos que siguen en curso.

• Retrospectiva: es fundamental realizar una reunión al final del sprint con los principales involucrados para reflexionar sobre el sprint: ¿Qué nos fue bien? ¿Qué nos fue mal? ¿Qué acciones de mejora podemos probar en el próximo sprint? La Gestión de Portafolio de Proyectos en mi experiencia requiere de una maduración muy progresiva con tiempos largos, por eso es fundamental tener este espacio de retrospectiva periódica para poder incorporar elementos de mejora continua que nos ayuden a madurar. 

• Roles:

• Equipo: se busca contar con los referentes de los principales sectores involucrados (por lo menos los sectores "cuellos de botella"), para que puedan definir como realizar los proyectos y definir temas de riesgos, estimaciones de esfuerzos, dependencias, etc. Luego van a ser los que ejecutan los proyectos.

• Scrum Master: es un rol vital para sostener el proceso, marcar el ritmo, facilitar las distintas reuniones y levantar impedimientos. En los casos donde apliqué esta idea, solía ser cumplido por la Oficina de Gestión de Proyectos (PMO).

• Dueño de Producto: es quizás el rol más difícil de trasladar a la Gestión de Portafolio de Proyectos. 
• Una de sus responsabilidad es identificar y canalizar los proyectos de los distintos sectores. Para esta responsabilidad nos apoyamos en un referente en cada sector, quien en conjunto con la PMO tenía la responsabilidad de relevar todos los nuevos proyectos de un sector. 
• Para la responsabilidad de priorizar y acordar los proyectos que quedan en el Portafolio de Proyectos, recurrimos en varios contextos a un Comité de Portafolio que represente los intereses del nivel más alto en cuanto a este portafolio (en un caso los responsables máximos del sector de sistemas, en otro caso los responsables máximos de la empresa). Tenían como rol elegir, eventualmente modificar y validar el Portafolio de Proyectos, para luego comunicarlo. 
• Para la responsabilidad de seguir el avance del portafolio y disparar eventuales acciones necesarias, fue una responsabilidad compartida entre la PMO y este Comité de Portafolio.

Gestión de Portafolio de Proyectos con Scrum

Algunas Lecciones Aprendidas hasta acá...

Como mencionaba antes, todavía me faltaría aplicar esta idea por completo durante varios ciclos de Gestión de Portafolio de Proyectos, pero sin embargo, les quiero comentar algunas lecciones aprendidas que puedan ser de utilidad para otros...

• El Time-Boxing de Scrum para duración de sprints y duración de sus distintas practicas es fundamental en la Gestión de Portafolio de Proyectos.Es muy tentador para una organización dilatar los plazos para sentirse más confiado y cómodo con ciertas decisiones de la Gestión de Portafolio. Sin ser demasiado extremista, a veces es mejor tener un Portafolio de Proyecto definido en base a aproximaciones que no tener nada.

• La Mejora Continua es muy importante en la Gestión de Portafolio, y como mencionaba antes la maduración es lenta. Por eso el enfoque iterativo con retrospectivas periódicas es una base fundamental para acelerar esta maduración y lograr buenos resultados.

• En Scrum, la priorización suele tener en cuenta el valor de negocio y el esfuerzo estimado. En la Gestión de Portafolio, se incluye explicitamente los Riesgos combinados de los proyectos.

• En Scrum se suele acordar el alcance del Sprint de acuerdo a la capacidad (velocidad) del equipo. En la Gestión de Portafolio esta Capacidad puede analizarse en función del esfuerzo requerido en varios sectores, y es tipico que se limite el alcance del Portafolio de acuerdo a otras restricciones como Dependencias y/o Presupuesto.

• En los distintos contextos donde lo implemente esta idea, los Tiempos de Refinamiento del Backlog (o Inventario de Proyectos) solían ser largos (varias semanas), ya que requerían reuniones con y entre varios sectores. Con lo cual no se puede esperar al fin del Sprint para empezar con estas actividades, y se genera superposición entre el final del Sprint y la preparación para el próximo. En consecuencia, las acciones de mejora identificadas en la retrospectiva a veces serán aplicables no en el próximo Portafolio sino en el siguiente. 

• A modo de ejemplos, les cuento algunas Acciones de Mejora que surgieron en los contextos donde apliqué esta idea:

• No incluir en la Gestión de Portafolio los proyectos con duración estimada menor a 1 mes.

• Explicitar y estandarizar el calculo del valor del proyecto para que sea el mismo para todos los proyectos.

• Involucrar más sectores en las estimaciones de esfuerzo de los proyectos. 

• Luego de las estimaciones por sector de los proyectos, hacer una segunda ronda juntando todos los sectores para poder aclarar en el momento dudas y cuestiones de alcance de los proyectos.

• Además de la restricción de capacidad por sectores involucrados, incluir una restricción para que no se pueda tener en el Portafolio más de 4 proyectos por líder/sector.

Conclusiones

Hasta ahora, veo que usar los mecanismos propuestos de Scrum para la Gestión de Portafolio de Proyectos ha sido bastante acertado. Espero profundizar su uso en varios ciclos de Portafolio en el futuro. ¿Qué les pareció la idea?

Para aprender más sobre Scrum, te recomiendo el taller Proyectos Ágiles con Scrum, de Kleer.