PRINCE2® en entornos ágiles (parte 1) – Esquema de procesos

En un post anterior comentábamos los beneficios de gestionar los proyectos en base a PRINCE2®, por el hecho de que este método permite definir claramente roles y responsabilidades, dotar a los proyectos de una estructura de gestión por niveles para disponer de un mayor control, poner el foco en el negocio, por su simplicidad y capacidad de adaptación y por su vocación de aprendizaje y mejora continua.

¿Pero estos beneficios son igualmente válidos cuando hablamos de proyectos en entornos ágiles? PRINCE2, como referente de un modelo de gestión de proyectos tradicional, ¿puede sernos de ayuda cuando nuestra organización nos demanda resultados rápidos, de valor para el negocio, o será un elemento de ralentización y burocratización?

En primer lugar, conviene tener claro que ágil no significa caótico, y precisamente cuando la organización persigue obtener resultados finales que se transformen en beneficios, utilizar PRINCE2 dota a los métodos ágiles de un framework de governance que permite a la organización disponer de mayores garantías de éxito.

PRINCE2 se basa en Principios (aquello que debe cumplirse siempre, en todos los proyectos), Temáticas (aspectos especializados que deben gestionarse en todos los proyectos) y Procesos (secuencia de actividades que deben realizarse en todos los proyectos). Uno de los principios es la adaptación al entorno de proyecto. Entonces, si el entorno de proyecto es ágil, ¿Cómo adaptamos PRINCE2? En este primer post intentamos identificar qué aspectos debemos tener en cuenta a la hora de adaptar los procesos.

El esquema de procesos de PRINCE2

omo vemos, PRINCE2 define tres niveles de gestión del proyecto: Nivel de Dirección (corresponde a lo que PRINCE2 llama la Junta de Proyecto, el máximo órgano de dirección del proyecto), nivel de gestión (correspondiente al trabajo del Project Manager) y nivel de entrega (correspondiente al trabajo del equipo, donde se realiza todo el trabajo técnico). El desarrollo de los métodos ágiles se producirá en el nivel de entrega.

Durante el pre-proyecto se obtendrá la aprobación formal del proyecto, y durante la fase de inicio se realizará el trabajo correspondiente de sentar las bases del proyecto para entender qué se hará, cuando se entregará, cuanto nos costará, cómo se realizará y quién lo hará. Es decir, la planificación global del proyecto, equivalente al Inception o sprint 0 cuando hablamos de métodos ágiles. Por lo tanto, los procesos de Puesta en Marcha e Inicio del Proyecto no tendrán cambios importantes, pero al tratarse de proyectos ágiles, esta planificación será de alto nivel, indicando especialmente los puntos de decisión más importantes para el negocio (releases principales), que conformarán las fases de gestión del proyecto.

Dentro de cada fase, los procesos de Control de una Fase y Gestión de la Entrega de Productos gestionarán la realización de las iteraciones o sprints y las validaciones de los incrementos de producto. El control de un proyecto ágil requerirá, eso sí, de técnicas, herramientas y habilidades diferentes a las de los proyectos tradicionales.

Los procesos de Gestión de Límites de Fase y Cierre de Proyecto, se encargan de finalizar una fase de gestión o un proyecto, revisando el trabajo realizado y preparando el trabajo para la fase siguiente, o para el post-proyecto. En proyectos ágiles se combinarán en cierta manera, dado que la finalización de una fase, y por lo tanto, la puesta en marcha de una release, implica un traspaso a usuarios y equipo de operaciones, con lo que deberá realizarse un cierto Cierre al final de cada fase de Gestión.

Por último, aunque estemos en proyectos ágiles, siempre será necesario el proceso de Dirección de un Proyecto donde la Junta de Proyecto (representada por los intereses de negocio, de usuario y de proveedor) tomará las decisiones más importantes del proyecto (entre ellas, continuar o no continuar, en función del Business Case).

En próximos posts explicaremos cómo adaptar cada una de las temáticas de PRINCE2 a entornos ágiles.