El paradigma del Project Manager a tiempo parcial

No es raro que nos enfrentemos a la gestión de varios proyectos a la vez. Es algo normal, y dependiendo de la complejidad del proyecto, podemos ver a Project Managers que gestionan hasta quince proyectos a un mismo tiempo. Ahora podríamos hacernos la pregunta de si estos quince proyectos son proyectos, o son requisitos proyectizados, pero ese es tema para discutir en otro post.
 
Lo curioso en este asunto de la dedicación parcial a la gestión viene cuando a la hora de asignar un jefe de proyecto te das cuenta de que si quieres sacar el proyecto adelante de acuerdo a las restricciones de la oferta, sólo te queda presupuesto para un project manager al 10%. Preguntas que por qué es esto así, y la respuesta es que el cliente así lo quiere, que con cuatro horas de jefe de Proyecto a él le basta para que prepare las reuniones y le cuente como va el proyecto.

Bajo esta perspectiva el project manager va a emplear 4 horas a la semana para:

• Reunirse
• Tomar requisitos
• Convocar y asistir a reuniones
• Gestionar a los stakeholders
• Gestionar al ciente
• Generar informes para el cliente
• Realizar tareas de gestión de personas
• Evaluar riesgos
• y un sinfín de acividades adicionales.

Es entonces cuando te das cuenta de que tienes un problema no tanto por la dedicación del Project Manager que al final será la que tiene que ser, sino porque no se está valorando el trabajo de coordinación y liderazgo que ejerce el project manager como engranaje para conseguir que el proyecto salga adelante. Bajo este enfoque podemos empezar a sospechar que para nuestro cliente el proyecto no es demasiado importante y es común que en este tipo de situaciones se sufra para conseguir llevar el proyecto adelante.

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.

La importancia de La Certificación PMP

Llevo preparando personas para obtener la certificación PMP desde hace más de cinco años y en todos los grupos surge la misma pregunta en la primera sesión ¿Voy a aprender algo nuevo? La respuesta es que siempre se aprende algo nuevo, que sin dudarlo vamos a aprender todos de todos, pero que nadie piense que con esta certificación vamos a encontrar la fórmula magistral para hacer las estimaciones definitivas desde el primer día de proyecto.

Empecemos por entender que PMBOK no refleja una metodología, PMBOK es un estándar. ¿Qué quiere decir eso? Pues que se trata de una recopilación de buenas prácticas que tenemos que aterrizar a la manera como queremos gestionar los proyectos en nuestro ámbito. La metodología se debe construir de acuerdo a las prácticas que aporten un valor claro. Usaremos aquello de PMBOK que necesitemos y lo que realmente encontremos e utilidad; el resto, lo desecharemos.

En un acercamiento radical podríamos decir que PRINCE2 podría haber sido el resultado de aplicar PMBOK a una gestión de proyectos predictiva focalizada en un caso de negocio inicial con un claro componente de gestión estructurada, o que scrum es una metodología basada en PMBOK y orientada a productos que no tienen un alcance cerrado desde el principio del proyecto.

La certificación PMP te prepara para conocer cuales son los procesos de gestión genéricos de manera que se pueda gestionar un proyecto dentro de un marco/empresa orientado a la gestión por proyectos. Por encima de los procesos están los estándares de especialización que PMI elabora a través de los voluntarios de la organización. (de lectura obligada una vez obtenida la certificación)

La mayoría de las organizaciones tienen un mapa de procesos muy parecidos a los expuestos y recogidos por PMBOK. Sólo es necesario un pequeño esfuerzo para mapear los procesos de compañía  con el estándar PMBOK. Que nadie espere que los procesos vayan a ser los mismos ni por supuesto que se vayan a llamar igual. Normalmente los procesos de compañía suelen ser un mix de los proceso recogidos en PMBOK. El caso más radical que conozco es el de una multinacional que tiene tres macroprocesos para la gestión de los proyectos extremo a extremo.

Además, la certificación PMP te permite estructura el conocimiento. Normalmente conocemos la mayoría de las recomendaciones y buenas prácticas recogidas en PMBOK, pero es necesario que las apliquemos en el orden correcto. La certificación nos ayuda a enfocar y fijar ciertas pautas de manera que quedan ancladas como foco de nuestra gestión.

Y para terminar, la certificación PMP no garantiza que el poseedor sea un buen Project Manager. La certificación PMP garantiza que en un momento dado conociste una extensa lista de técnicas y herramientas, con las entradas y salidas necesarias para usarlas y emplearlas correctamente.

¿Aporta un valor la certificación? Sin duda alguna, sobre todo teniendo en cuenta los costes asociados y la proyección profesional que aporta, aunque como todo en  esta vida, lo importante o es el conocimiento, sino lo que podemos hacer con él.

El project Manager y el Mercenario

En una charla reciente con mi amigo Ricardo, de esas delante de la máquina de café, surgió un tema que me hizo pensar sobre el porqué de la ética profesional. La conclusión es que realmente es necesaria.

Planteémoslo desde el punto de vista siguiente: Te dan un objetivo y un presupuesto. Transformas los objetivos en trabajos a realizar, los pones en un cronograma, compruebas que tienes dinero suficiente y te lanzas a la ejecución.

Imagina que en lugar de un Project Manager hablásemos de un mercenario. Se plantea un objetivo, un tiempo para cumplirlo y un presupuesto. Un mercenario no se para ante nada. Sigue adelante para terminar cuanto antes, cobrar y librar cuanto antes las guerras de otro. A un mercenario no le importa lo que queda ni quién venga detrás. Tiene claro el objetivo y si por ello debe arrasar con poblaciones enteras, lo hará.

Hablemos ahora del Project Manager: no podemos parar ya que el año que viene no tendremos presupuesto para este proyecto. Tenemos que terminar para poder entregar y no tener que andar con peticiones a los comités de inversiones. Por no decir que ya estamos en noviembre y el presupuesto está casi cerrado. Estoy tentado de completar en tiempo y entregar cuanto antes, sin fijarme en cómo queda el proyecto, sin importar si el proyecto está documentado, y sin pensar en las horas que van a tener que echar los de Operaciones cada vez que haya que dar de alta un usuario, que hacer un retoque o simplemente modelar procesos operativos. Toda esta ineficiencia cuesta una cantidad de dinero terrible a la compañía, pero he entregado a tiempo. Incluso he tenido bajas en el equipo. Todo sea por la entrega.

Es aquí donde entra la ética. Si el Project manager se transforma en un mercenario, tras de sí no quedará nada. Es necesario restringir las normas de juego para evitar pérdidas económicas cuantiosas, economizar en la operación (se supone que el producto del proyecto tiene una vida mucho más larga que el proyecto en sí) y no dejar el staff con un reguero de empleados estresados y descontentos...

Al final, la ética, produce dinero.