Why can't I be good as a Project Manager?

Why can’t I be good

Why can’t I act like a man

Why can’t I be good

And do what other men can

I'd like to look in the mirror

With a feeling of pride

Instead of seeing a reflection

Of failure a crime

Lou Reed's song: Why can't I be good

After many years in the profession, I’ve met many people who claimed to be Project Managers, but actually they weren’t. Even worse, they didn’t have the attitude to become one. These people found their comfort zone (they didn’t recognize that, though) in deciding and executing every single technical detail, so proficient in their domain of expertise that no one could do their job, catch up their pace, deal with crisis, handle complaints, etc. When leading project teams, they did not delegate many technical tasks, as they tried to control team members’ work by controlling over the technical details, discussing on “how to do” more than on “what to do”.

Dirección de Proyectos: Una profesión poco agradecida

-¡Si no pasa na'!

Pero que sepas que, en no pasando na', ser eres...

-¿Que soy qué?

-Un técnico.

-No, perdona, yo soy el Director del Proyecto,

lo que pasa es que, por esta vez, tengo que hacerlo yo todo.

-Desde el cariño te lo digo: Que sepas que ser eres...

– José Mota (cuando parodie nuestro gremio ;-)

A lo largo de mi trayectoria profesional, me he encontrado con muchas personas que decían ser Directores de Proyecto, pero que no lo eran, y peor aún, no tenían la actitud para llegar a serlo. Estas personas, aunque no lo reconocían, encontraban su zona de confort en ejecutar o decidir todas y cada una de las actividades de tipo técnico, especializándose tanto en su ámbito de dominio que nadie más podía hacer ese trabajo, igualar su ritmo, solucionar las crisis, atender las quejas, etc. Cuando estas personas lideraban equipos, no delegaban todas las tareas técnicas, y la forma de controlar a los miembros del equipo era entrando en los detalles técnicos, debatiendo más el “cómo hay que hacerlo” que el “qué hay que hacer”.

Cuando los jefes se daban cuenta de que el proyecto iba muy mal, o bien cancelaban el proyecto o bien les reemplazaban sin dudarlo, y entonces ellos vivían un tremendo drama: estaban totalmente identificados con el proyecto, el proyecto eran ellos mismos, cuando les “mataban” el proyecto era como si les mataran a ellos mismos.

Me peleo por conseguir la gente que quiero

Cuando estudiaba el PMBOK, me llamó la atención la separación entre el proceso 6.4 Estimar los Recursos de las Actividades (un proceso de planificación, donde hay que decir, por ejemplo, que necesito 4 técnicos de sistemas y 2 programadores), del proceso 9.2 Adquirir el Equipo del Proyecto (un proceso de ejecución, donde ya ponemos nombres y apellidos a la gente que necesitamos).

Hasta entonces, yo pensaba que los dos procesos se hacían a la vez: Necesitaré un 50% de Pepe y a Luisa al 100%. Que existiera un proceso en el grupo de “ejecución”, es decir, cuando ya el proyecto está en marcha, ya me hacía pensar que el Director de Proyectos debía dedicar mucho más esfuerzo en la adquisición del personal. PMBOK también dice que los grupos de procesos se solapan, nada impide que la ejecución se solape con la planificación (esta actividad la tendrá que hacer Pepe para que dure sólo 15 días), o incluso con el inicio (Luisa sería recurso clave en este proyecto).

Me atrevo a hacer promesas

Para muchos jefes, proactividad en gestión de proyectos significa predictibilidad. Las operaciones del día a día son predecibles y uniformes, pero un proyecto no es así. Esfuerzos, costes, plazos, hitos, entregas, problemas, etc., no se distribuyen uniformemente: hay más entregas al final que a la mitad, la fecha de los hitos puede variar mucho. Se podría decir que muchas veces, la principal razón por la que nos colocan al mando de un proyecto es porque quieren que alguien vaya informando todas estas variables. 

El paradigma de la era industrial les hace pensar que pueden aspirar a un control determinista del proyecto: si controlan estas variables, controlan el proyecto. Por esta razón, estos jefes le pedirán muchas veces su mejor estimación sobre un plazo y un presupuesto, se lo apuntarán, y luego le volverán a preguntar cuando se aproxime la fecha, o el coste incurrido supere un umbral. 

Yo planifico mi proyecto

El primer síntoma de que un Director de Proyectos no es proactivo es que no tiene una planificación actualizada y creíble. En otras palabras, no sabe qué va a pasar en su proyecto la semana que viene, el mes que viene... Esto es muy grave. No por la mala imagen que proyecta como persona ineficaz, que también, sino sobre todo por la desmoralización que suele producir esto en los miembros del equipo.

No hay excusa para que un Director de Proyectos no tenga una planificación preparada, escrita o pensada, primero para organizarse él mismo, pero también para quien la pueda necesitar. 

El primer hábito de una persona eficaz: Sea proactivo

El primer hábito de Covey se titula: “Sea proactivo”. Es el primer hábito para superar el estado de madurez “dependiente”. Nadie puede aspirar a ser eficaz si le afecta todo lo que ocurre fuera. Si tiene un mal día o un buen día dependiendo de si llueve o hace sol, esa persona no puede ser independiente. Las personas independientes llevan consigo “su propio clima”. Saben reconocer su zona de control y actuar desde ella. Las personas “no somos como los animales”. Los animales son reactivos: ante un estímulo siempre reaccionan igual, están programados por el instinto o el adiestramiento.

Comprometerse con el proyecto

Un Director de Proyectos no será eficaz si está permanentemente abrumado por el entorno. No va a entregar un buen producto si se queja constantemente de la empresa, de la falta de recursos disponibles capacitados, de lo infradimensionado que está su proyecto, de lo mal que se ha vendido, de la inmadurez corporativa en gestión de proyectos, las pesadas herramientas corporativas, la burocracia excesiva, la falta de apoyo de la dirección, etc. Es muy posible que tenga razón en todas estas quejas, pero lo primero es el proyecto, y al proyecto le perjudica mucho que quien lo dirige piense así. Además, no se puede demostrar, pero ocurrirá esto: esta persona tendrá mala suerte.

Comprometidos como EQUIPO con la primera iteración

Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. 

En este post, los miembros del equipo dedican dos semanas a terminar otro proyecto mientras la analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores. Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para planificar la primera iteración y comprometerse como equipo para terminar las historias más prioritarias. El resultado es un compromiso firme del equipo sobre 4 historias que miden 18 puntos.

¿Quiere saber cómo se planifica esta primera iteración?

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.