Planificación por Paquetes de Trabajo

Cuanto más uso la WBS (Work Breakdown Structure) más clara me queda la necesidad de llevar a cabo la planificación a través de la descomposición por paquetes de trabajo. Y cuando hablo de paquetes no me refiero a tareas de proyecto, que se encuentran a un nivel más bajo en la descomposición.

 

Los beneficios que he encontrado en la planificación y seguimiento por paquetes vienen por diferentes vías:

1. Simplicidad a la hora de elaborar el reporting: Reportar exclusivamente sobre el grado de avance de los paquetes de trabajo, evitando entrar en los detalles técnicos.  Nos permite la elaboración de reportes ejecutivos sin necesidad de entrar en los detalles técnicos.
2. Identificación sistemática de todo el alcance del proyecto: definir todo el trabajo que tenemos que llevar a cabo en el proyecto. La WBS suele tener vida propia y se modifica a lo largo del ciclo de vida del proyecto (si ves que la frecuencia de las modificaciones no disminuye, empieza a pensar que tienes problemas de definición de alcance en el proyecto)
3. Tener una estructura jerárquica del trabajo, de manera que podemos relacionar el trabajo de alto nivel y el de bajo nivel o detalle
4. Identificar un Checklist de referencia con el cual verificar que llevamos a cabo todo el trabajo requerido y que no se nos olvida ninguna pieza clave a la hora de conseguir los objetivos del proyecto. 
5. Asegurarnos que no vamos a hacer nada que no esté en esta herramienta ya que esos trabajos no aportarían valor específico a los objetivos definidos. 
6. Focalizar y enfocar los esfuerzos del proyecto. Focalizar nos sirve para distinguir lo que aporta valor al proyecto y lo que no. Enfocar nos sirve para identificar en qué momento nos estamos desviando de los objetivos del proyecto y volver a la senda adecuada.

Soy incapaz de empezar una planificación en el tiempo si no tengo primero definidos los entregables* del proyecto con una pequeña descripción de lo que se espera por parte del cliente y de lo que entendemos todos y cada uno de los integrantes del equipo.

 Posteriormente, esas notas iniciales son enriquecidas a medida que hablamos con todos los integrantes del proyecto y se vuelven a compartir de nuevo con el cliente, los proveedores y cuantos considere oportuno. En ese proceso de construcción iterativa vamos descubriendo elementos (paquetes) que en una primera exploración se obviaron, de manera que recogemos de manera sistemática: 

• Los objetivos del proyecto
• Las necesidades del cliente
• Las restricciones a las que nos enfrentamos  

y un sinfín de detalles de menor calado, pero no menos importantes, que nos completan la visión y la necesidad de ejecutar paquetes no contemplados inicialmente para conseguir la satisfacción del/los clientes/usuarios. 

En esta construcción iterativa nos podemos encontrar con necesidades de contribuyentes diferentes al cliente, que intentan colocar sus necesidades dentro del proyecto con el fin de conseguir diferentes objetivos, como por ejemplo disminuir la carga de trabajo de sus departamentos, ahorrar costes, o implementar funcionalidades que pretenden usar posteriormente y cuya construcción correrá a cargo de los presupuestos del proyecto. En el otro extremo podemos encontrarnos con una cierta resistencia (a veces hostilidad) a colaborar, de manera que a posteriori aparecerán tareas ocultas que no estaban contempladas inicialmente y que supondrán elementos que normalmente impactan desde el diseño de la solución hasta la fecha de fin de proyecto.

Trabajar con la WBS no es sencillo si nunca antes lo has hecho. Las primeras veces que elaboramos una WBS podemos caer en el error de dejarla ahí y no saber qué hacer con ella. Si queremos trabajar con esta herramienta es necesario que consigamos el hábito de releer la WBS de vez en cuando e identificar si de todo lo que estamos haciendo falta algo, sobra algo, o es necesario revaluar los paquetes de trabajo.

Revisar la WBS debe ser un hábito y debemos entender que la revisión de la WBS tiene que venir acompañada de un sólido sistema de reporting en el que basarnos para asegurar la integridad de la misma (que al fin y al cabo es parte de nuestra baseline de alcance si nos basamos en un enfoque formal de Gestión de proyectos).

Para más información acerca de cómo usar y construir la WBS en tus proyectos, consulta las primeras páginas  del "Practice standard for Work Breakdown Structures second Edition" del Project Management Institute.

(*) Entendemos por entregable cualquier elemento autocontenido que sea una pieza lo suficiente significativa sobre la cual poder medir con el fin de identificar el avance del proyecto y que se consigue a través de la ejecución de una o más tareas. Este entregable no tiene por qué ser un elemento de entrega a cliente final. Puede ser perfectamente un elemento interno al proyecto que nos permite