Project Forecast

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

Bajar al barro

Fuente: www.elconfidencial.com

Una de las peores cosas que le pueden pasar a un gestor de proyecto es no disponer de un equipo lo suficientemente dimensionado. Y cuando digo dimensionado me refiero a cuatro variables (y no por orden):

1. Experiencia
2. Conocimiento
3. Número
4. Compromiso

Lo cierto es que si te falla el equipo en alguna de estas variables lo normal es que tu esponsorización de proyecto sea muy débil. Si tu proyecto no cuenta con el equipo adecuado, debería ser porque los recursos están en otro proyecto más interesante para la compañía. Si eso no es así, el sistema de gestión del porfolio de la empresa tiene una vía de agua: No se están dedicando los recursos a lo que debieran.

El caso es que por muchas razones, el Project Manager a veces debe bajar a la trinchera (ocurre más veces de las deseables) para colaborar en tareas operativas del proyecto. Esto tiene un riesgo, y es que te pierdas en el bosque. Si entras en la operativa del proyecto es común que se diluya la la referencia de gestión y nos centremos más en el corto plazo que en el medio y largo plazo, con lo cual perdemos la visión del proyecto. Es común esta situación en los casos que el Project Manager desarrolle actividades dentro de su proyecto.

Un Project Manager no puede perder nunca el foco del proyecto. Debe permanecer fiel a los objetivos marcados. Cuando se entra en la operación del proyecto, se pierde la noción del objetivo a medio plazo, y nos dejamos embriagar por la experiencia de conseguir el objetivo operativo del corto plazo. Se trata de un fenómeno fisiológico que debemos evitar. Lo mejor para estos casos es tener verdadera urgencia en cerrar estas tareas, y volver a tomar el control y la visión global del proyecto. Es necesario despachar estas tareas cuanto antes, y volver a nuestras actividades de gestión. Para ello es bueno consultar la WBS del proyecto de vez en cuando (para mi los lunes por la mañana es el mejor momento) para tener en cuenta lo que es importante y por lo que nos están pagando, que viene a ser el conseguir terminar los paquetes de trabajo. Cualquier cosa que no esté en la WBS no pertenece al proyecto, y nuestro trabajo como Project Manager es hacer que las cosas ocurran, no hacerlas.

Si nuestro proyecto es pequeño, o tenemos un rol doble de Project manager y "Team Member", es normal que nos arremanguemos a menudo, pero cuando lo hagamos, debemos cuidarnos de:

1. Si otro miembro del equipo puede hacerlo dentro de unos parámetros de calidad/tiempo/coste adecuados, tú no pintas nada.
2. Aportar un valor claro. Define los procesos, el marco de referencia y todo aquello necesario para operar la actividad. Los detalles de más bajo nivel que los desarrolle alguien con un coste de oportunidad inferior al tuyo.
3. Tener alguien al alado al cual enseñar para que se haga cargo de la actividad cuando esté medianamente lanzada.

Podemos y debemos ayudar, pero tenemos que evitar la operativa tanto cuanto nos sea posible, aunque nos guste.