¿Cómo gestionas tu proyecto? ¿Ágil o tradicional?

La gestión eficaz de los proyectos y el cumplimiento de los objetivos previstos, son aspectos clave para el éxito de las organizaciones. Así, cada día está más extendida la aplicación de metodologías y buenas prácticas en la gestión de los mismos. De hecho, las empresas demandan a profesionales que sean capaces de manejar adecuadamente sus ideas y transformarlas en productos y por ende en beneficios, de forma profesional, planificando y controlando adecuadamente el trabajo de sus equipos.

 

PMBOK O AGILAntes que nada: hay que determinar el enfoque del proyecto

Cada proyecto es único. Esto es algo que no se puede olvidar. Conforme aumenta el número de profesionales de la gestión de proyecto, en algunos casos, se van detectando fundamentalismos. Quiero decir que hay defensores acérrimos del uso de una metodología, desechando de inicio –incluso despreciando- el resto.

Pero esto puede ser un error. Como hemos dicho, cada proyecto es único y su approach o estrategia para él, también lo debe ser. Esto no significa, que si una organización desarrolla proyectos muy similares, tiene que cambiar de estrategia para cada uno, sino que debe dedicar tiempo y recursos a analizar si debe seguir con su modelo, o por el contrario si otro tipo de enfoque sería más adecuado.

 

Ciclo de vida del proyecto

Uno de los aspectos clave cuando nos enfrentamos a cómo enfocar el modo de gestionar un proyecto, es definir el tipo de ciclo de vida (PLC Project Life Cycle) por el cuál va a discurrir.

El PMPBoK (Project Management Book of Knowledge –PMI) expone que básicamente, existen tres tipos:

  • Predictivos: o en cascada. En este caso, de pueden definir previamente, las fases por la que va a pasar el proyecto, y los entregables a producir al final de cada una. Es adecuado el uso de este tipo de estrategias cuando se tiene una idea clara del producto del proyecto que se desea obtener.

ciclos de vida predictivos

  • Cíclicos o iterativos: también conocidos como incrementales. En este caso, el ciclo de vida se va repitiendo de forma cíclica, de manera que al final de cada ciclo, obtenemos un resultado más definido.

ciclos de vida ciclicos - Versión 3

  • Adaptativos o ágiles: para entornos donde no se tiene claro cuál será el producto a definir y su alcance, los modelos ágiles se basan en el desarrollo de productos o entregables (trozos del proyecto) que se presentan al cliente, de forma que éste pueda valorarlos y seguir con el proyecto. Son ciclos cortos, Sprints (2 – 4 semanas) y el objetivo es ser capaces de entregar al cliente “cosas” que pueda tocar y que funcionen y así comprobar que cumplen con sus requisitos.

ciclos de vida agiles

Estos modelos se basan en el Manifiesto Ágil, que desarrollaron 17 expertos en el desarrollo de software en Salt Lake City en 2001. Exponiendo sus bases en la siguiente declaración:

 

“…hemos llegado a valorar:

  • A los individuos y su interacción, por encima de los procesos y sus herramientas.
  • El software que funciona, por encima de la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más a los de la izquierda.”

 

¿Cuál es el mejor?

Según mi opinión, todos son buenos o malos, dependiendo del tipo de proyecto, la organización, sus restricciones y equipo disponible. Más o menos como decía Ortega y Gasset:

“Yo soy yo y mis circunstancias”

Traduciendo a idioma project: “El proyecto es el producto y sus circunstancias”.

 

Debo que tener en cuenta, qué quiero conseguir (producto del proyecto), cómo es el cliente y la organización en la que se va a desarrollar el proyecto, y en cuánto tiempo y costo hay que conseguirlo.

Así, si tenemos entre manos a un proyecto de software o investigación, donde el cliente no tiene claro qué resultado se va a alcanzar y tan sólo disponemos de unos requisitos básicos, podríamos usar técnicas ágiles tipo SCRUM. Pero cuidado! Alguna vez he odio a expertos profesionales que cuando detectan un trabajo desordenado y pobre en un equipo y se lo recrimina, éstos le responden:

“No somos un desastre, somos ágiles”.

 

Para proyectos donde se tiene más definidos los requisitos y el por ende el futuro proyecto a realizar, bajo mi punto de vista, es más adecuado el uso de metodologías más “tradicionales” basadas en las buenas prácticas, donde el referente indiscutible es el anteriormente citado PMBOK, o el método PRINCE2. Los dos se pueden aplicar a todo tipo de proyectos, independientemente de su tamaño y complejidad, pero evidentemente hay que adaptarlos para que la gestión de cada proyecto se eficiente y no se burocratice sin necesidad, llegando a un equilibrio entre el control y el beneficio obtenido.

 

Y lo podemos mezclar todo!: También podemos usar un mix de metodologías.

Imaginemos un proyecto tipo para desarrollar un teléfono móvil. En un principio, se puede partir de una idea o una necesidad detectada por el departamento comercial de la compañía con unos pocos requisitos. En este caso, se podría usar un enfoque predictivo básico, definiendo las fases por las que debería pasar el proyecto (con objetivos temporales y con los entregables que se obtendrían en cada una de ellas). Y diseñando un Master Plan o plan director, que nos de una visión global del proyecto y sus objetivos principales a alto nivel.

 

Así, podríamos arrancar con una fase de diseño conceptual de producto. Una vez finalizada, aplicaríamos el principio de PRINCE2 de gestión por fases. Lo que significaría analizar el resultado obtenido, actualizar el Master Plan y planificar en detalle la siguiente fase. Usaríamos una planificación progresiva o roll wave planning.

Además podríamos tener una fase (o un entregable principal) que fuese el desarrollo del software a implementar en el terminal. Y para este caso concreto, en enfoque podría ser más ágil y usar SCRUM.

 

Conclusión: un proyecto está lleno de proyectos

Efectivamente, un proyecto puede tener un enfoque determinado global, pero para cada paquete de trabajo que un equipo tiene que desarrollar (o para cada fase), se puede –y se debe- poner en cuestión la solución que más se ajusta para el cumplimiento de los objetivos. Por lo tanto, hay que olvidarse de fundamentalismos y ser pragmáticos!.

 

Siguiendo éste enlace, puedes ver más información sobre nuestros cursos de formación en gestión de proyectos.