El oficio de Project Manager es especialmente duro por muchas razones, pero principalmente una: Nos ponen al mando de un proyecto para echarnos la culpa. Echar la culpa al Project Manager es muy fácil, todo el mundo sabe hacerlo. Somos responsables de que el proyecto cumpla los objetivos de gestión: que termine en coste, en plazo, con la calidad deseada, cumpliendo las expectativas de los interesados, etc. Para culpar al Project Manager solo hay que decir que “el proyecto ha durado 20 meses y no 15, como estaba previsto cuando se aprobó”, o que “se han gastado 300 mil euros y no 250”. Nuestro fracaso, en el peor de los casos, es binario: éxito si cumplimos los objetivos de gestión, fracaso si no es así.
Para saber jugar bien el rol de Project Manager, lo más importante son las habilidades sociales, a mi juicio esto es lo que más marca el éxito final. No obstante, es necesario dominar ciertas habilidades duras como son la capacidad de descomponer el alcance, controlar fechas y costes, etc. A veces la explicación de los retrasos o los sobrecostes es que no hemos ido controlando ese grano fino de tareas elementales, y el impacto se ha ido agregando hasta provocar retraso o sobrecoste.
Yo he aprendido que el control del proyecto debo adaptarlo a dos niveles. Por un lado debo controlar el menudeo de quién hace qué y cuándo, en el lenguaje que entienden los miembros del equipo. Por otro lado debo controlar que los objetivos se cumplen en el lenguaje que entienden los miembros del comité de seguimiento: ¿qué sobrecoste y retraso acumula el proyecto a nivel de cuenta de control? ¿cuál es el pronóstico a la conclusión? ¿qué riesgos pueden afectar a los objetivos si se materializan? ¿qué problemas o incumplimientos están aconteciendo con los proveedores? etc.
Los miembros de los comités de dirección, altos ejecutivos, responsables del project governance de una gran organización, necesitan información actualizada no sobre los detalles, sino sobre los indicadores clave de gestión. Necesitan asegurarse de que los proyectos cumplen sus objetivos (gestión del suministro) y además deben gestionar la demanda: ¿qué nuevos proyectos deben emprenderse? Deben priorizar según su grado de alineamiento, retorno económico esperado, realización de beneficios de alto nivel, etc. A veces la priorización conlleva cancelar o retrasar un proyecto en marcha para adelantar o mover recursos a otro proyecto más interesante para el negocio. Podemos decir que el project manager se encarga de hacer correctamente lo que se ha aprobado (do the thing right), mientras que los órganos de gobierno se encargan de hacer lo correcto (do the right thing). En este interesante vídeo de Microsoft (muy bien producido, por cierto) pueden visualizar muy claramente cómo en un futuro se gestionarán programas y portafolios.
Esta forma de entender la gestión del proyecto en 2 niveles, hacia abajo (equipo) y hacia arriba (governance) me recuerda la estructura de hábitos de Stephen R. Covey, que interpreté en mi libro Los Hábitos de un Director de Proyectos Eficaz.
El Dr. Covey decía:
“La eficacia duradera se consigue practicando hábitos que producen victorias privadas: ser capaz de hacer promesas y cumplirlas...”
Yo relaciono estos 3 hábitos de la victoria privada con el desempeño técnico.
“... y por otro lado hay que practicar hábitos para conseguir victorias públicas: involucrar a los demás en el problema y buscar juntos la solución.”
Yo relaciono estos 3 hábitos de la victoria pública con el gobierno del proyecto.
Todo proyecto ha de descomponerse hasta elementos gestionables. Se podría decir que el Project Manager tiene una especial habilidad para hacer listas que transforman lo grande (inmanejable) en pequeño (manejable). Por ejemplo:
- descomponer los riesgos agregados en riesgos causales
- descomponer los requisitos de negocio en requisitos técnicos
- descomponer los esfuerzos de alto nivel en tareas detalladas
La clave para controlar un proyecto grande y complejo es dividirlo en partes gestionables. Cuando hacemos una Estructura de Desglose del Trabajo (EDT), ya tenemos en los los nodos finales los paquetes de trabajo, que ya nos permiten empezar a desglosar costes y tiempos. A la hora de controlar el alcance, quizá no sea conveniente reportar a nivel de paquete de trabajo porque no tenga interés informativo para el comité de seguimiento. Mi recomendación es que al pintar la EDT también se indique qué nodos serán cuentas de control. Debemos recubrir el 100% el alcance del proyecto sumando las cuentas de control.
Muchas veces utilizamos estas cuentas de control para determinar los códigos contables donde los miembros del equipo deben incurrir horas y gastos. Nosotros sabremos todo el desglose de horas y gastos, pero la dirección no tiene por qué recibir esa sobrecarga de datos de desempeño, no tiene sentido informativo, para ellos, no es información de gestión.
Podemos decir que los miembros del comité de dirección pueden conformarse con la información ejecutiva a nivel de cuenta de control, ¿pero qué hay debajo? El siguiente peldaño bajando por la escalera de gestión del proyecto son las actividades, cuando ya no sólo nos interesa el qué sino el cuándo. Las actividades son los elementos que queremos ver representados en un cronograma. Controlar cuándo empiezan y acaban es necesario para conseguir que el proyecto termine en plazo.
Aquí no tiene interés informativo representar todo los elementos temporales. Yo puedo saber cuándo serán las reuniones de seguimiento, pero es un error representarlas en un cronograma porque no tiene interés informativo. Un diagrama Gantt debería incluir la información necesaria para gestionar que se termina dentro del plazo, calculando desviaciones y pronósticos. Cuando programamos un cronograma, la tentación es apuntar todo lo que hay que hacer, pero hay que pensar que luego hay que controlar cuándo empieza y termina cada tarea. Programar varias actividades para la misma persona el mismo día, tareas que duran menos de un día, o muchas tareas en paralelo, luego tiene el inconveniente de que el control se hace imposible. Todos hemos visto Gantts con más de mil tareas, ¿verdad? ¿Recuerdan a qué se dedicaba el project manager? ¿a gestionar el proyecto o a gestionar la herramienta? Esta práctica es un error a evitar que se conoce con el nombre de microgestión.
Tampoco hay que incluir en un cronograma las actividades que solo tienen sentido para los miembros del equipo. Las actividades (elementos de gestión para terminar en plazo) hay que dividirlas en tareas detalladas, que yo prefiero no representarlas en un Gantt, porque creo que se gestionan mejor con herramientas de task management como Asana.
Personalmente creo que resulta efectivo separar el mundo de las actividades del mundo de las tareas técnicas. Recuerden este inspirador vídeo de Rita Mulcahy cuando decía que no hay que preguntar ¿qué porcentaje has completado?, hay que preguntar ¿has terminado ya?