Gestión de Proyectos

Qué es un Project Manager

Responsable de proyecto, jefe de proyecto, project manager, líder facilitador del proyecto, líder de proyecto, gerente de proyecto… ¿todo esto significa lo mismo, son expresiones que se usan indistintamente, o cada una tiene un significado y aplicación particular?

En este artículo no pretendemos definir académicamente conceptos ni ideas, sino hablar de forma práctica y concreta de la realidad que se vive “en la oficina”, en el puesto de trabajo, de cómo se cuentan y se viven las situaciones en las empresas todos los días; así que… sí, podemos considerar todas esas expresiones como sinónimos, o más bien, debemos pensar que el project manager es TODO eso:

• Responsable de proyecto: con “responsable” queremos decir que, tanto si el proyecto va bien como si va mal, el que tiene que rendir cuentas es una única persona: no es quien debe realizar el trabajo técnico, tampoco es quien debe estimar ni planificar todo el trabajo (ojo con ésto, que trataremos más adelante), ni tampoco el que asigne cada una de las tareas a realizar a cada uno de los miembros del equipo… pero sí es quien tiene que dar la cara por el equipo, tanto si se acierta como si se comete un error.

• Jefe de proyecto: ¡cuidado con esta expresión! En el contexto actual de transformación digital, las empresas quieren (y deben) huir de la idea del “jefe de…”, porque esta forma de pensar y de hablar implica un perfil de gestión con estilo “ordena y manda”, es decir, “el jefe de proyecto dice a las personas lo que deben hacer”. Puede que esto haya sido lo natural hasta hace no tanto tiempo, pero ahora el enfoque de liderazgo y gestión ágil de proyectos se impone por goleada al enfoque tradicional.

Funciones del Project Manager

La principal función del project manager es “gestionar” el proyecto, no cabe duda, pero ¿y esto qué significa?

Para empezar, lo que NO debe significar es aplicar constantemente un estilo de microgestión del trabajo, más bien al contrario: el mejor project manager es el que establece los objetivos a cumplir, por ejemplo negociando y acordando un mapa de productos mínimos viables con el cliente (tanto si estamos desarrollando una solución digital como si no) que guíe el desarrollo del producto y sea la herramienta para determinar qué tareas hacer en cada momento organizadas en iteraciones (de una semana, dos semanas…), obteniendo al final de cada una de ellas una validación del trabajo conseguido.

Todas las empresas de todos los sectores avanzan hacia este estilo de liderazgo facilitador del proyecto; rompamos el mito de que el estilo ágil de gestión es sólo para ambientes TI, pero es cierto que los proyectos TI son ideales para aplicar las habilidades de gestión ágil.

¿Y qué sector o empresa no necesita a IT para poder funcionar? Sin temor a equivocarnos, podemos decir que todas lo necesitan, así que el mejor profesional de la gestión de proyectos TI será el que mejor sepa aplicar este estilo de dirección ágil y facilitador.

Considerarse un facilitador no quiere decir que dejemos de ser “responsables” del proyecto, es decir, el project manager IT no se va a librar de hacer los “informes de seguimiento” que se le pidan, puesto que facilitar significa aliviar el trabajo administrativo de los perfiles técnicos, ayudar en la interlocución con negocio, etc… pero no que dejemos de ser los portavoces del proyecto de cara a explicar el estado de situación (sea bueno o malo).

Se suele decir que el “90% del tiempo del gestor de proyecto lo dedica a la comunicación…” y esta máxima no sólo sigue siendo cierta, sino que lo es cada vez más: el gestor de proyecto es la correa de transmisión de toda la maquinaria, es quien construye los canales de comunicación (sí, es el project manager el que debe cargar con el aburrido trabajo de convocar las reuniones, reservar las salas físicas o digitales, asegurarse de que los convocados puedan asistir…).

Sin comunicación no se pueden gestionar las expectativas de los interesados, pero… ¡¡también cuidado con este término, “interesados”!! No son sólo interesados aquellos que “tienen interés” en nuestro proyecto, aunque suene extraño; lo que ocurre es que se ha tomado el término “interesado” como traducción de “stakeholder”, cuyo significado realmente es “impactado”, así que podemos tener:

• Interesados que están a favor del proyecto, que nos ayudarán, que quieren que salga adelante y harán nuestra gestión más fácil.

• Interesados que no quieran que nuestro proyecto avance ni salga bien. Por ejemplo, si el objetivo es automatizar una serie de tareas, es posible que el éxito del proyecto signifique que algunas personas se queden sin trabajo; desde un punto de vista corporativo puede ser una buena idea, pero desde el punto de vista de estos trabajadores, sin duda no sólo no nos ayudarán, sino que debemos esperar que hagan todo lo posible para que el proyecto no tenga éxito.

Así que un gran error es gestionar las expectativas y comunicarse sólo con los interesados que están a favor del proyecto… más bien al contrario, la mejor idea (además de la mejor práctica de gestión) es prestar más atención a qué interesados pueden bombardear y dañar al proyecto.

Otra función principal del project manager es fomentar la maduración del equipo de trabajo, reconociendo el estilo de liderazgo que debe aplica en cada momento. Como decíamos antes, buscamos hoy en día un estilo facilitador… lo cual suena muy bien, pero debe aplicarse con criterio según el momento de madurez de cada equipo de personas, es decir:

• Un equipo que aún se está formando, porque el proyecto está arrancando o porque las personas apenas se conocen entre ellas, necesita un manager más “directivo”, que no les haga perder tiempo ni “enredarse” discutiendo quién hace qué, por qué, cuál es el proceso de trabajo… en estos momentos conviene una actitud más directiva de asignación del trabajo.

• Un equipo que está en proceso de maduración, debería llevar a cabo sesiones de brainstorming para que, entre las personas del equipo, se tomen decisiones de qué prácticas hacer más, hacer menos, empezar a hacer, dejar de hacer… por ejemplo podemos desarrollar radiadores de información como el “radar” en el que las personas valoran de 0 a 5 cómo de seguros o cómodos se sienten a la hora de resolver el trabajo técnico, hablar con negocio, detallar requisitos, hacer estimaciones fiables, determinar fechas de entrega etc. En este punto, el gestor de proyecto debe provocar y retar al equipo para que cambie su status quo, y proponerles este tipo de reuniones. Así, las decisiones de cómo trabajar la toma el equipo, no el responsable de proyecto, con lo que las personas se comprometerán mejor con lo que decidan.

• Si un equipo ya es maduro, lleva cierto tiempo trabajando junto, conocen sus puntos fuertes y débiles, sus costumbres… siendo claros, el gestor de proyecto debe “tratar de no molestar”, dejarles trabajar, facilitarles los recursos necesarios (entornos de trabajo, herramientas, una oficina cómoda o negociar con la empresa para trabajar en remoto, organizar la agenda de reuniones con el cliente…), es decir un enfoque de “dejar hacer”.

Responsabilidades de un Project Manager

Si queremos hablar de responsabilidades, también tenemos que hablar de salarios… porque el salario de un gestor tiene mucho más que ver con su responsabilidad, que simplemente con sus “tareas”. No deberíamos preguntarnos simplemente “¿cuánto gana un project manager?” sin antes preguntarnos: ¿Qué valor añadido estamos dispuestos a aportar como tales? En infinidad de conversaciones con project managers IT, escuchas comentarios del estilo:

• “… es que mi cliente tiene un proceso lento y pesado…”
  1. “… me paso el día haciendo informes de seguimiento…”
  2. “… en mi empresa la casuística es muy particular y aquí todo funciona de forma lenta…”
  3. “… me paso el día actualizando el plan de proyecto para que se parezca a la realidad…”

Pues aquí es donde radica la diferencia entre un “project manager IT”, y un “buen project manager IT”; si queremos considerarnos buenos profesionales de la gestión de proyectos, como decían en una famosa película, ¿Cuál es nuestro oficio?

• Si el cliente tiene un proceso lento y pesado, ayudémosle a agilizarlo: por ejemplo, haciendo la documentación más simple, más ejecutiva, más resumida, más al grano en definitiva (más vale un buen documento hecho en un día, que un documento pluscuamperfecto que requiere una semana).

• Si nos pasamos el día haciendo informes de seguimiento… ¿por qué no los hacemos más sencillos? El reporte de un proyecto no debe decir que “vamos bien, mal, regular, ligeramente atrasados, o algo adelantados…” nada de eso sabemos lo que significa. En un proyecto de un año de duración, una semana es un “ligero retraso”, pero esa semana es inaceptable en un proyecto de 2 meses… El estado de un proyecto no es algo subjetivo sino objetivo en base a dos indicadores numéricos señalando cómo vamos en coste, y cómo vamos en tiempo.

• La casuística de cada empresa, de cada proyecto, siempre es “única y particular”, por eso precisamente no existe un manual o una norma única de qué pasos seguir o cómo actuar para todos los proyectos a los que nos podemos enfrentar. La clave es el ajuste de cómo llevamos a cabo la gestión: más predictiva o tradicional, más ágil, orientada a la microgestión, orientada a facilitar el trabajo…

• Si los planes de proyecto no sirven como guiones del trabajo, ¿por qué no dejar de hacerlos? Y eso va en serio: las habilidades de un project manager no consisten en hacer planes… sino en conseguir que los proyectos se entreguen en fecha, con calidad, y cumpliendo un presupuesto; los planes sólo son herramientas para conseguirlo. Un enfoque de trabajo ágil minimiza el tiempo de preparación de planes antes de trabajar, y se centra más en la colaboración durante el trabajo… ¿no parece el camino a seguir si los planes predictivos no funcionan?

Por tanto, entre las cualidades de un project manager está la de quejarse un poco menos del entorno, de las circunstancias y del cliente, pero aplicar más una amplitud de miras para ser proactivo en la resolución de los problemas y aplicar las buenas ideas, no sólo las buenas prácticas, que parecen funcionar en cada proyecto.

Cómo ser Project Manager

Muchos se preguntarán qué estudiar para ser project manager… a lo cual hay respuestas: tenemos un amplio abanico de certificaciones oficiales, y ampliamente reconocidas como project managers (tanto para IT como para otros ámbitos) como las PMP, ACP, CAPM (estas tres del Project Management Insitute), Prince2, y otras más específicas como Scrum Manager (ésta sí está más orientada al mundo TI).

Prácticamente todos los project managers IT vienen de carreras técnicas como Informática, Telecomunicaciones… y han pasado por roles de desarrollo, programación, diseño técnico, análisis, etc… este conocimiento cercano de la realidad del trabajo resulta del todo conveniente para entender, y apoyar, argumentos a favor de estimaciones y plazos de entrega, por ejemplo.

Pero las competencias de un project manager van más allá de cierto conocimiento teórico sobre prácticas de gestión de proyectos, digamos que quien ejerce el rol de project manager se “forja” en ello: no se puede estudiar en un libro cómo resolver un conflicto entre dos miembros del equipo, por ejemplo, cuando no están de acuerdo con el tiempo estimado para una tarea. Esto hay que vivirlo, y hay que aceptar que, aunque podríamos hablar de cuáles son los niveles de conflicto posibles y las “herramientas y técnicas” posible para resolverlos, al fin y al cabo, cada persona es única, la personalidad cuenta, la experiencia de cada uno cuenta, la actitud de cada uno cuenta… y por eso lo que hace el project manager es adaptar su trabajo a cada caso.

Así podríamos resumir el rol de un project manager, destacando también su importancia: no se trata de asignar el trabajo constantemente a cada persona del equipo técnico, no se trata de decirle a todo el mundo lo que tiene que hacer… se trata de orientar, de facilitar, de conseguir que el trabajo salga adelante porque los miembros del equipo “quieren” que salga adelante, cuentan con su project manager como punto de apoyo y también como orientación. Y también el project manager debe ejercer el rol de protector y portavoz del equipo, creando un entorno de seguridad (en todos los sentidos) para las personas de forma que puedan, y quieran, dar lo mejor de sí mismos por el bien del proyecto, y por lo tanto por el bien de todos, incluido el project manager.