Agile Project Management vs. Waterfall Project Management

Durante décadas la gestión tradicional de proyectos, llamada también Waterfall (o cascada en español) por el símil que se produce entre el diagrama de bloques y los “bancos de cascadas” (véase figura siguiente), ha permitido (y, por supuesto, permite actualmente) aumentar las probabilidades de éxito de un proyecto.

De hecho, estas probabilidades de éxito se magnifican, entre otras y según el PMI, si se presta especial atención a:

• Fijar correctamente los objetivos y compartirlos con el equipo.
• Conseguir el apoyo del sponsor y la dirección de la empresa.
• Realizar una correcta gestión de requisitos y estimación y control de la triple restricción (Alcance, Coste y Tiempo).
• Gestionar correctamente los .
• Gestionar los stakeholders y sus expectativas.
• Cuidar y garantizar las comunicaciones.

Quizá habrás notado que existen tipos de proyectos donde es relativamente más fácil gestionar o prestar atención a los puntos anteriores. Efectivamente, y los podemos identificar a grandes rasgos analizando y respondiendo a la siguiente pregunta:

“Si realizamos un profundo análisis de requerimientos, ¿podemos estar razonablemente seguros de que estos no variarán sustancialmente durante el ciclo de vida del proyecto? Y, en todo caso, si varían, ¿podemos crear un método fiable de gestión integral de cambios para canalizarlos?”

Por tanto, Waterfall es el método más adecuado, económico y fácil de gestionar para proyectos que tienen:

• Objetivos bien establecidos.
• Etapas bien definidas.
• Enfoque lineal.
• Facilidad o método fiable para analizar los requisitos.
• Se puede crear una línea base.
• La finalización de todas las tareas da como resultado el éxito del proyecto.

Normalmente, hablamos de proyectos grandes con grandes presupuestos, necesidad de muchos recursos y alcances razonablemente claros que permiten hacer unas buenas EDT (Estructura de Descomposición de Tareas) o, en inglés, WBS (Work Breakdown Structure).

Sin embargo, aun siguiendo las mejores prácticas Waterfall, hay proyectos que se retrasan o no cumplen las expectativas de los stakeholders (clientes, directivos, sponsors…). Este tipo de proyectos son aquellos en los que en general:

• Los requisitos iniciales no tienen por qué mantenerse estables durante todo el ciclo de vida del proyecto. De hecho, pueden variar sustancialmente, aparecer nuevos o bien descartarse anteriores.
• Es necesario mostrar rápidamente “entregables” al cliente para validaciones tempranas y permitir gestión de cambios en cada iteración.
• En cada iteración debe haber un producto (o “entregable”) funcional.
• No se puede generar una triple restricción completa para el proyecto, sino únicamente para cada iteración.

Para este tipo de proyectos es recomendable usar metodologías ágiles, las cuales se caracterizan por generar múltiples iteraciones con requisitos estables solo para esa iteración (no para el proyecto completo) y que entregan un producto “funcional” al final de la misma. La figura siguiente muestra este comportamiento:

Los siguientes 3 ejemplos pueden ayudar a comprender el tipo de proyectos que requieren de gestión ágil de proyectos:

• Creación de una start-up (o lean start-up). Hoy en día es impensable crear una compañía desde cero sin generar múltiples iteraciones y validaciones parciales de productos o servicios intermedios, así como estar atento a todos los condicionantes internos y externos (competencia, proveedores, clientes…) para reajustar, cambiar o añadir/quitar nuevos requerimientos en cada una de las iteraciones.
• Proyectos de software de pequeño o mediano tamaño que requieren de un “time-to-market” lo más reducido posible, aunque sea con producto mínimo viable. Muchas veces no se puede esperar a tener el proyecto finalizado para lanzar las versiones Beta y gracias a esas versiones obtener nuevos requisitos para las siguientes iteraciones.
• Creación de nuevos productos con validación de usuarios.

La conclusión es que no hay una metodología mejor que otra, sino que se ha de tener en cuenta el tipo de proyecto al cual nos debemos entregar para aplicar la metodología que mejor se adapta al mismo.

Un buen jefe de proyectos debe estar preparado: conocer y dominar ambos tipos de metodologías para usar la más adecuada en cada caso; ya que, si no, es posible que en función de la experiencia del Project Manager, este intente aplicar la metodología que más conoce o con la que más cómodo se sienta a cualquier tipo de proyecto (independientemente de la naturaleza del mismo) generando graves problemas al proyecto y posiblemente también a empresa ejecutora y/o cliente, como los que se muestran en la tabla siguiente que compara el tipo de proyecto con el método que el jefe de proyectos decide aplicar.