Un proyecto ágil es una asignación temporal para crear un producto, servicio o resultado único, en que los requisitos no están claros al principio y deben elaborarse progresivamente a partir de la retroalimentación continua de los interesados (=valor), que regularmente atienden a demostraciones donde pueden ver un incremento del producto del proyecto funcionando.
En un proyecto ágil, después de cada demostración, los interesados manifiestan abiertamente su opinión sobre el incremento que han visto y el product owner utiliza esta retroalimentación para validar los requisitos (en agile se dice «historias de usuario») o bien para eliminar incertidumbres. Esta forma de avanzar en un proyecto se denomina «ciclo de vida orientado al valor».
Si los requisitos pueden consensuarse en una fase inicial, debido a la incertidumbre funcional, lo que suele ocurrir en proyectos de ingeniería y construcción (también denominados proyectos EPC), se considera un error metodológico seguir un modelo de ciclo de vida orientado al valor. Lo correcto es seguir un modelo de ciclo de vida orientado a la planificación, predictivo, u orientado a procesos: A partir de los requisitos se determina el alcance, y a partir del alcance se estiman los tiempos y los costes, y se desarrolla un plan para la dirección del proyecto especificando el resto de áreas de gestión: calidad, recursos, comunicaciones, riesgos, adquisiciones e interesados.
Si los requisitos no pueden consensuarse en una fase inicial, lo que suele ocurrir en proyectos de software, se considera un error metodológico seguir un modelo de ciclo de vida orientado a la planificación. En este caso, lo correcto es seguir un modelo de ciclo de vida ágil, orientado al valor, adaptativo, o que da la bienvenida a los cambios. Hay que determinar el tiempo disponible, calcular el coste de un equipo estable, y dividir el proyecto en fases sucesivas que se entregan cada 2-3 meses (releases), y en cada release suelen demostrarse incrementos en reuniones con los interesados, que tienen lugar con periodicidad fija, típicamente cada 2 semanas. La retroalimentación de los interesados nos permite validar los requisitos entregados y deducir los nuevos. Podemos decir que el alcance se va desarrollando progresivamente.
Los proyectos pueden aplicar ciclos de vida ágiles en unas fases y ciclos de vida predictivos en otras. Cuando esto ocurre, se dice que el proyecto sigue un modelo de ciclo de vida híbrido.
Un project manager profesional suele estar capacitado para gestionar proyectos predictivos y ágiles. Se le presupone un conocimiento práctico para aplicar las técnicas y herramientas que permiten que cualquier proyecto entregue el valor y cumpla los objetivos de gestión, principalmente para que termine a tiempo y dentro del presupuesto. Evidentemente, hay multitud de factores que pueden provocar que no se entregue el valor o se cumplan los objetivos de gestión y entonces se considera que el proyecto ha sido fallido y el project manager suele considerarse como el principal responsable. Los buenos project managers suelen registrar las evidencias del fracaso no al final del proyecto o fase, sino en cada reunión de seguimiento, cuando es posible que los involucrados ayuden a buscar soluciones antes de que sea demasiado tarde.
Casi siempre, es injusto culpar al project manager del fracaso del proyecto, dada la multitud de variables que lo afectan, pero para eso precisamente nos ponen al mando los jefes, para tener un culpable identificado.
Los jefes nos quieren al mando de un proyecto para tener un culpable identificado 🙁
Sabiendo que estas son las reglas del juego, juguemos bien nuestras cartas: Los project managers profesionales queremos rendir cuentas en reuniones de seguimiento, en las que podemos informar y también involucrar a los miembros del comité de seguimiento, de manera que la culpa no sea solo nuestra.
¿No hay Reglas en un Proyecto Ágil?
Los directivos de las organizaciones, cada vez que autorizan un proyecto ágil, suelen experimentar una disonancia cognitiva:
- Quieren que el proyecto cumpla los objetivos de gestión y entrega de valor: es decir, que termine antes que una fecha, por debajo de un presupuesto y satisfaciendo las necesidades, como cualquier otro proyecto.
- Saben que el equipo debe auto-organizarse sin jefes. Cuando haya dudas, ya preguntarán a otras personas que tienen el conocimiento del negocio (e.g. product manager). ¿Para qué hace falta un project manager en un proyecto ágil?
Cuando hablamos de los proyectos más representativos del modelo ágil, los proyectos software, hay una complacencia alarmante sobre los incumplimientos. Es habitual escuchar la frase «Yo no he visto ningún proyecto software que cumpla fechas o que no cueste más del doble».
¿De verdad te parece que esto es un problema sin solución? Si dejas que los técnicos realicen sus tareas, pero nadie rinde cuentas sobre el proyecto, ¿por qué te sorprende que no se cumplan las fechas, o que el coste final sea muy superior? Los proyectos ágiles también se deberían controlar.
Los proyectos ágiles también se deben controlar. Los directivos tienen derecho a preguntar avances y pronósticos. Hay que anticiparse a los posibles problemas, priorizar funcionalidades, facilitar el desarrollo del equipo, gestionar las expectativas de los interesados, etc.
Las grandes organizaciones, cada día tienen más proyectos cuyos requisitos no están claros, y la complejidad aumenta cuando estos proyectos deben gestionarse de forma conjunta, como programas o portafolios. No hay soluciones fáciles, pero seguro que estos problemas tienen solución. Dentro de cualquier solución, el project manager debería tener un papel fundamental.
El pasado día 31 de mayo comenzamos a plantear la problemática de controlar proyectos ágiles. La grabación puede verse en el siguiente enlace: https://youtu.be/JhFxKRPDppQ
El próximo día 15 de junio a las 18:00, hora de España, trataremos de mostrar con ejemplos prácticos cómo se pueden controlar proyectos ágiles individuales y agrupados como programas o portafolios, gracias a nuestra herramienta PMPeople.
Enlace al evento en directo: https://youtu.be/1zhp3pvtkH0
La presentación (PDF) se puede descargar en este enlace https://bit.ly/2QGGHAi
Incluye los siguientes puntos:
- ¿Cómo aplica el Manifiesto Ágil en gestión de proyectos?
- ¿Cómo escalar Proyectos Ágiles?
- Algo pasa con el Software…
- ¿Para qué nos ponen al mando de un Proyecto?
- Un proyecto Ágil: El desarrollo de PMPeople
- Caso de Estudio Ágil, por Mike Cohn
- Demo: Caso de Estudio Ágil con PMPeople
PMPeople es la herramienta para la economía de proyectos. Se diseñó para unificar la gestión profesional de 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. 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.
