PMPeople: la herramienta para la PMO Ágil

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.

En PMPeople, un proyecto puede encontrarse en uno de los 4 estados mencionados (el estado ejecución incluye los procesos de monitorización y control). Si se trata de un proyecto predictivo, se entiende que, en estado de cierre, se transfiere un producto completo al cliente.

En los proyectos ágiles no se distingue una fase de planificación separada. Como los requisitos no están claros, es necesario iterar continuamente con los interesados para descubrir progresivamente el valor. La fase de ejecución se divide en cajas de tiempo llamadas releases, que suelen durar unos 3 meses. Al final de cada release, se transfiere un producto que será usado por los interesados.

Las funcionalidades (features) incluidas en una release se van elaborando progresivamente. La release se subdivide en otras cajas de tiempo denominadas iteraciones, que suelen durar 2 semanas. Al final de cada iteración, en una reunión cara a cara, el equipo de desarrollo demuestra las funcionalidades ante los interesados, que ofrecen retroalimentación inmediata.

Agile sigue un ciclo de vida iterativo-incremental:

• 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.

Normalmente, una release tiene unas 5 iteraciones. La última iteración, denominada iteración H (de hardening) no está destinada a producir un nuevo incremento para demostrar funcionalidades, sino para realizar los procesos de cierre formal de la release y la puesta en producción.

En proyectos ágiles, la planificación de un proyecto normalmente se hace al revés que en un proyecto predictivo. En un proyecto predictivo, se elaboran los requisitos para fijar el alcance, a partir del cual se estima la duración y el coste, produciendo un plan de proyecto. Se sigue un modelo de gestión basado en la planificación.

Por el contrario, en un proyecto ágil, se determina de antemano el tiempo que el negocio puede esperar para tener el producto, por ejemplo 18 meses. Un equipo ágil estable de 8 personas, durante 18 meses, tendrá un coste prefijado. Lo que hay que estimar, gracias a la involucración continua de los interesados, es el alcance, siguiendo un modelo de gestión orientado al valor. Si los interesados no se involucran (no atienden a las demostraciones, a los refinamientos, no resuelven rápidamente los impedimentos, etc.) el proyecto fracasará.

El PM profesional debe conocer en profundidad cómo se trabaja en un proyecto ágil: los roles, las ceremonias, los artefactos, etc. Debe ejercer un liderazgo servicial, facilitar la orientación al valor, etc. Las técnicas y herramientas dependerán del marco ágil utilizado. En Scrum, el equipo ágil tiene los siguientes roles:

• 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.

En SAFe, un equipo ágil puede incluir entre 5-11 Team Members.

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:

Los miembros del equipo completo pueden mostrarse en la opción INITIATION > Project Team:

El PM asigna a los miembros del Development Team en la opción PLAN > Plan Resources > Assign Team Members:

Opcionalmente, podría asignar también como Team Members al Product Owner y al Agile Coach. El PM puede dar acceso de gestión del proyecto al Product Owner y al Agile Coach, para lo cual debe incluirles con el rol de PMO Supportive.

Los interesados pueden ser asignados al proyecto por el PM en la opción INITIATION > Stakeholder Register:

Además de registrar los datos de cada interesado, el PM puede decidir si acceden al proyecto a través de la herramienta.

Por su parte, los interesados pueden unirse proactivamente al proyecto si conocen el código privado:

El PM, conjuntamente con el Product Owner, puede planificar las diferentes releases como paquetes de trabajo del proyecto, en la opción PLAN > Plan Scope:

Dentro de cada release puede haber típicamente entre 3-7 iteraciones. Las iteraciones siempre tienen la misma duración desde que la release comienza hasta que termina. Dependiendo de la release, una iteración puede durar entre 1-4 semanas. El cronograma del proyecto a cargo de un equipo puede visualizarse como sucesión de releases:

En PMPeople aconsejamos modelar la release como el nivel más bajo del cronograma de un proyecto ágil. El PM o el Product Owner pueden modelar las funcionalidades (features) como los requisitos o entregables que deben producirse dentro de cada release. PMPeople permite conectar otras herramientas como Asana o Jira, más apropiadas para la gestión de tareas, para gestionar los artefactos Product Backlog, Release Backlog, Iteration Backlog, Parking Lot, Information Radiators, etc.

Si es necesario, el PM puede planificar el coste horario y las horas de trabajo previstas para cada Team Member, en cada release, sus fechas previstas de entrada y salida del proyecto, etc. A partir del coste estimado por iteración (burn rate) puede planificar el coste de cada release y planificar la línea base de costes o curva S. El PM puede controlar el coste del proyecto siguiendo el estándar EVM:

Por lo que se refiere a la monitorización y control del proyecto, en cada fecha de seguimiento, el PM puede registrar la Situación Global del Proyecto para que pueda ser consultada por el resto de interesados:

El PM puede gestionar los costes del proyecto desde una perspectiva financiera, por partidas contables. Se desglosa la financiación en capítulos contables según sean flujos de caja positivos o negativos:

En cada seguimiento, el PM puede controlar los gastos reales frente a los planificados, y las fechas de los ingresos o pagos reales frente a la planificación:

En cada seguimiento, el PM puede realizar un pronóstico de la financiación, tal y como quedaría al final del proyecto:

En la sección LOGS, el PM puede registrar y controlar los riesgos, los supuestos y los incidentes:

Entrando en la opción Team Comments, el PM podrá revisar los comentarios provenientes de los miembros del equipo (los comentarios pueden ser anónimos):

El Agile Coach, accediendo como PMO Supportive, puede revisar los estados de ánimo comentados por los miembros del equipo en un periodo del proyecto, lo que resulta muy útil a la hora de recopilar datos para retrospectivas, en la opción LOGS > Happiness Index:

Si se reflexiona sobre alguna lección aprendida en lo relativo a la gestión del proyecto, el PM puede registrarla en la opción CLOSING > Lessons Learned Register:

En su día a día, los miembros del Development Team utilizarán principalmente herramientas de baja tecnología, o si no están coubicados, herramientas de gestión de tareas como Asana, Jira, etc. PMPeople puede ahorrarles mucho tiempo, además.

Un TM puede saber su papel específico dentro de cada release:

Un TM puede saber quiénes son sus compañeros:

Cualquier TM puede actualizar el Team Charter:

Un TM puede trasladar comentarios al PM, opcionalmente de forma anónima:

Un TM puede comentar su estado de ánimo diario (happiness index), de forma anónima:

Por último, pero no menos importante, en el caso de que los TM deban reportar horas y gastos, típico ejemplo de tarea no orientada al valor, PMPeople permite que realicen esta operativa de manera muy efectiva, vía Web o mejor aún, desde la aplicación móvil.

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.

Un programa desarrolla un producto coordinando varios proyectos:

El equipo resultante, sumando los diferentes equipos ágiles, que se denomina Agile Release Train (ART), puede incluir desde 50 a 125 Team Members.

En PMPeople, un Program Manager puede configurar un programa para gestionar el desarrollo de un producto. La forma más sencilla de añadir proyectos a un programa es a través del código privado del proyecto:

Los diferentes equipos ágiles trabajan como se describió anteriormente. Además, deben coordinarse para entregar los PI.

Por último, cabe pensar en soluciones corporativas cuyo desarrollo involucra a varios ART, incluso la contratación de proveedores externos. El Portfolio Manager puede incluir proyectos y programas en su portafolio. Los proyectos pueden ser suministrados por otra organización proveedora (gestión vía procurement):

En la gestión del portafolio tiene mucha importancia la priorización, el análisis financiero, compartir casos de negocio, la gestión de la capacidad, etc. Los Team Members suelen requerir organizarse en Comunidades de Práctica (CoP), Centros de Excelencia (CoE), etc.

Todas estas funciones pueden llevarse a cabo de forma ágil en PMPeople.

PMPeople se diseñó para unificar la gestión profesional los proyectos de las organizaciones, destacándose por los siguientes puntos:

• Diseñada por y para project managers profesionales, siguiendo los estándares de gestión de proyectos profesional.
• Productividad en línea (menos reuniones, menos documentos, menos flujos) por colaboración distribuida entre 12 roles especializados: Dueño de la Organización; 6 roles para la gestión de la demanda y 5 roles para la gestión del suministro.
• Aplicación freemium (uso gratuito por tiempo ilimitado, pago por uso, solo pagan los gestores) con usabilidad equivalente por web y por la aplicación móvil.

Comience a usar PMPeople gratis, sin límite de tiempo, sin límite de usuarios. En las organizaciones premium solo pagan los gestores, 20 euros al mes. Algunos roles (interesados, team members, patrocinadores y gestores de recursos) son siempre gratis. Podrá añadir o reducir usuarios premium según las necesidades reales de su organización. En todo momento, tendrá acceso a nuestro soporte interactivo por Slack. Nuestros servidores se encuentran dentro de la UE. Si lo prefiere, el software puede quedar alojado en sus instalaciones.