Bye bye, gestión tradicional de proyectos

Bye bye, gestión tradicional de proyectos

Efectivamente. Todo tiene su momento y de todo hay que aprender. Y eso es lo que me ha pasado con la gestión de proyectos. Desde que inicié mi etapa como gestor de proyectos hace ya algunos años he intentado aplicar una y otra vez metodología tradicional para el desarrollo de proyectos, con amplias definiciones de alcance y ciclos de vida ‘waterfall‘ (entre fases del proyecto o dentro de las mismas), adecuándola a cada uno de los proyectos que debíamos desarrollar. Pero no ha acabado de funcionar. Siempre han existido disfunciones de alcance, coste o tiempo, hasta que empezamos a utilizar métodos ‘Lean’ y herramientas ‘Agile’. Coste: Pago por aquello que el mercado necesita No es que ahora no haya disfunciones, sino que ahora son parte del transcurso del proyecto y las gestionamos según la incertidumbre existente y el alcance definido. Se han acabado los márgenes de contingencia para gestionar la incertidumbre inherente a cada proyecto, porque nuestros clientes conocen esa incertidumbre desde el inicio y la ajustamos constante y conjuntamente. Ajustamos las personas del equipo de forma ágil en un tiempo corto para conseguir un objetivo concreto, en ‘sprints‘ que proporcionan prototipos. Las herramientas usadas provienen del mundo del software pero las aplicamos a todos los proyectos. Os recomiendo la lectura sobre desarrollo de software basado en prototipos. Alcance: Soy más rápido en obtener el resultado que deseo Estos prototipos ayudan al cliente a poder modificar su proyecto y variar alcances sobre la marcha, para el siguiente ‘sprint’, sin ser problemático para nadie del equipo, ni para el cliente, ni para el proyecto. Basándonos en este funcionamiento, muchas veces (dependiendo de la estructura y metodologías de la empresa cliente), nos encontramos que no hace falta una amplia y ardua gestión de cambios, con  documentos de aprobación de cambios infumables o comités de aprobación que analizan todas y cada una de las implicaciones que el cambio puede significar (mientras que la competencia prueba en el mercado si realmente dicho cambio es aceptado o no por los clientes). Tiempo: La constante fija Y al final de cada ‘sprint’, el cliente tiene aquello que ha pedido, con muy poco margen de error (como máximo el mismo número de días que ha durado el ‘sprint’, que nunca me ha sucedido). Y es que cada ‘sprint’ tiene una fecha fin que nadie cuestiona y en la que todas las partes están comprometidas, desde el cliente hasta el equipo que lo desarrolla y pone en marcha. Pero, ¿y todo lo que hacíamos hasta ahora? Seguimos aplicándolo, pero de otro modo. Por ejemplo, en cuanto al alcance, troceamos el proyecto con herramientas tradicionales como el ‘WBS‘, pero a alto nivel y a sabiendas de que éste cambiará muy probablemente. Si eres una ingeniería es probable que pienses que es necesario definir las tareas en las diferentes fases y que, cuan más definidas estén desde el principio, mejor. Y que no concibes una planificación sin un ‘diagrama de gantt‘ con sus dependencias, cargas, caminos críticos y posibles cuellos de botella. Pero yo te pregunto, ¿qué desviación típica tienes actualmente en los proyectos así planificados? ¿Con qué márgenes de contingencia trabajas? No creo que debas olvidarlas ni dejarlas de usar (yo no lo he hecho) pero si creo en que hay que saber adaptarlas. Y sigo preguntándote ¿Puedes asegurar cumplir cada una de las tareas en el tiempo y coste acordados, con plena satisfacción del cliente? Si es así, felicidades. Sino, te animo que pongas a prueba alguna de las herramientas que te proporcionan las metodologías ‘Lean y Agile’.]]>

Leave A Reply

Tu dirección de correo electrónico no será publicada.

*