
Debido a la vorágine actual provocada por la transformación digital, muchas Oficinas de Gestión de Proyectos (PMOs) ven como crece exponencialmente el número de proyectos que deben controlar, sin que este crecimiento venga acompañado de una mayor dotación de recursos. De la noche a la mañana, la alta dirección aprueba proyectos con alto componente tecnológico, que involucran trasversalmente a la organización y cuyos requisitos no están claros. Los comités de dirección piden a la PMO informes de estado, informes de riesgos, pronósticos de costes, etc. Los project managers piden recursos, orientación metodológica, etc. Los equipos piden cursos de agile, coaches, espacios de trabajo colaborativos, herramientas, etc. Muchos representantes del negocio siguen creyendo erróneamente que agile es una moda pasajera, o que solo aplica a proyectos software, etc.
A estas alturas, la PMO corporativa ya tiene claro que la forma de gestionar los proyectos adaptativos no debe ser predictiva, sino ágil. Una PMO Ágil tratará de poner en práctica ciertos paradigmas:
- Los proyectos deben orientarse al valor en lugar de a la planificación.
- Los representantes del negocio deben involucrarse para proporcionar retroalimentación continuamente.
- Debe haber personas con un rol funcional, especializadas en gestionar los requisitos y por otro lado, equipos responsables del desarrollo técnico. Es decir, hay que separar el qué, del cómo.
- La PMO no debe centralizar la gestión porque se convertiría en un cuello de botella. No debe introducir burocracia ni flujos de aprobación. Debe conseguir sus objetivos sin requerir más recursos.
- La PMO debe fomentar modelos de gestión distribuida: los project managers, program managers, portfolio managers, functional managers, resource managers, etc., deben repartirse la gestión en sus respectivas áreas de conocimiento, para que la PMO pueda enfocar mejor su trabajo.
- La coordinación de múltiples equipos debe realizarse siguiendo ciertos marcos de escalado ágil como SAFe, DA, LeSS, etc.
La herramienta PMPeople no evita la necesaria colaboración ágil cara a cara dentro de los equipos, la participación en las distintas ceremonias, la utilización de otras herramientas para comunicarse, radiar información, gestionar tableros virtuales, etc. Sí facilita enormemente, no obstante, la colaboración entre las personas involucradas en la gestión de proyectos, utilizando una herramienta accesible desde la aplicación móvil o vía Web, favoreciendo la orientación al valor y eliminando el desperdicio. También facilita el escalado ágil cuando deben colaborar grandes equipos.
Gracias a PMPeople, la PMO puede pasar de ser un cuello de botella, a una entidad facilitadora que logra entregar más proyectos de valor con éxito, en menos tiempo y con menor coste.
Gestión de Proyectos Ágiles
Los marcos ágiles no mencionan el rol del project manager porque se diseñaron para la gestión de productos, no de proyectos. No obstante, el rol PM es requerido siempre que la organización aprueba un proyecto que debe terminar dentro un plazo determinado y por debajo de un presupuesto. El PM profesional se responsabiliza, entre otras cosas, de que el proyecto ágil termine a tiempo y sin exceder el presupuesto, tratando de satisfacer los requisitos del grupo de interesados. En un proyecto predictivo, que sigue un ciclo de vida en cascada, la mayoría de los requisitos pueden aclararse y consensuarse en una fase inicial del proyecto, lo que permite fijar el alcance, estimar el coste, el plazo, etc. y finalmente elaborar un plan detallado. Este plan para la gestión del proyecto se usará como referencia para comparar el desempeño real con el previsto y tomar acciones correctoras, a fin de terminar cumpliendo los objetivos de gestión. La Guía del PMBOK® divide los procesos de gestión en 5 grupos de procesos, que pueden solaparse en el tiempo, aunque por simplificar se presentan siguiendo un orden secuencial:
- Grupo de Procesos de Inicio: La organización debate si el proyecto ha de hacerse o no. En caso afirmativo, el patrocinador lo aprueba y firma un documento llamado acta de constitución del proyecto.
- Grupo de Procesos de Planificación: El equipo de gestión del proyecto elabora, con la ayuda de expertos, un plan para la dirección del proyecto que servirá como referencia para ejecutar y controlar el proyecto. En los proyectos predictivos, a veces se practica la planificación gradual, es decir, el plan se va versionando a medida que se conoce mejor información, pero lo más habitual es que este documento sea bastante estable, como es el caso de los proyectos de ingeniería y construcción.
- Grupo de Procesos de Ejecución + Grupo de Procesos de Monitorización y Control: Son dos grupos interrelacionados, diseñados para ejecutar el plan y para monitorizar periódicamente el desempeño, que si no es el esperado para cumplir los objetivos de gestión, llevará a tomar las acciones correctoras necesarias.
- Grupo de Procesos de Cierre: Una vez que todos los entregables han sido aceptados por el cliente, se procede a la comunicación del cierre y demás procedimientos relativos al cierre formal y la transición del producto del proyecto a la organización solicitante.



- Ciclo Iterativo significa que, a intervalos regulares, se busca la retroalimentación de los interesados.
- Ciclo Incremental significa que el producto se va elaborando como las capas de una cebolla, primero el corazón con las funcionalidades más importantes y después las sucesivas capas de menor importancia. Se hace crecer el producto con nuevas funcionalidades mientras se va refinando lo ya construido.
- En cada demostración, se enseña un incremento potencialmente usable, de manera que si la release termina anticipadamente, se puede entregar un producto que funciona.


- Product Owner (PO): Es el responsable de maximizar el valor del producto del trabajo del DT. Es la única persona responsable de gestionar el Product Backlog, que no es otra cosa sino una lista priorizada de requisitos (user stories, features, epics, etc).
- Development Team (DT): Se compone de profesionales que realizan el trabajo para entregar un Incremento de Producto terminado, que potencialmente se podría poner en producción al final de cada iteración. El DT demuestra el Incremento de Producto a los interesados en la revisión de la iteración. Solo los miembros del DT participan en la creación del Incremento de Producto. Descomponen las funcionalidades en tareas técnicas y las gestionan en el Iteration Backlog. Se auto-organizan para entregar valor al final de cada iteración.
- Agile Coach (CO): Es el responsable en promocionar y apoyar los métodos ágiles, ayudando a practicar la teoría, prácticas, reglas y valores. El CO es un líder servicial para el DT. Ayuda a los interesados a entender qué interacciones con el DT pueden ser útiles y cuáles no. Ayuda a todos a modificar estas interacciones para maximizar el valor creado por el DT.
- Customers (CU): Son los interesados que deben involucrarse para orientar el valor. Si bien se considera que forman parte del equipo completo, su nivel de compromiso es menor.
PMPeople para Proyectos Ágiles
En PMPeople, un PM puede crear un proyecto dentro de una Business Unit (BU). Aunque el proyecto aún no haya sido aprobado formalmente por la organización, el PM puede iniciar el proyecto actualizando los datos básicos del proyecto, la información resumida sobre los beneficios esperados, el acta de constitución, el equipo extendido, así como el registro de interesados:




















PMPeople para Grandes Equipos Ágiles
La forma propuesta por SAFe para escalar el trabajo de varios equipos ágiles, para construir conjuntamente un producto, consiste en sincronizar los incrementos obtenidos por cada equipo al final de cada iteración y sumar las diferentes releases en lo que se denomina un Program Increment (PI). Habitualmente, cada PI se compone de 5 iteraciones y cada iteración dura 2 semanas.



