Andares de un proyecto

La productividad de un líder

Publicado el Febrero 29th, 2012 en Ejecución, Recursos Humanos, Comunicaciones por admin

Existe una injustificada discusión entre lo que tendría que hacer el líder del proyecto y lo que realmente está haciendo y dicha discusión tiene que ver con el nivel de involucramiento que éste debería tener con los entregables técnicos del proyecto. Para salir pronto de dudas, el líder del proyecto debería estar más involucrado con el funcionamiento del equipo, que con la fabricación de los entregables. Algunos autores dicen que un administrador de proyectos nunca debería encontrarse en la ruta crítica del proyecto y esto es porque sus actividades, de naturaleza principalmente administrativas, pueden retrasar el trabajo de los demás compañeros. Esto no quiere decir que un líder de proyectos no debería participar en la construcción de entregables de un proyecto, pero si advierte que hay diferencias entre las actividades de un miembro del equipo y su líder.

estres-laboral.jpgComo decimos en México: “ni tanto que queme al santo, ni tanto que no lo alumbre”. Como PMs necesitamos documentar, necesitamos reportar avances, necesitamos documentar riesgos y actualizar el registro de problemas, necesitamos actualizar el cronograma y volver a empezar otra vez. Sin embargo, además de todo esto, necesitamos ser productivos. Necesitamos entregar resultados. Los resultados que un PM entrega no sólo son documentos escritos, sino resultados a través del equipo del proyecto. Que se haga lo que está planeado hacerse, que se entregue lo que se prometió con el nivel de calidad que se esperaba. Que la gente haga lo que tiene que hacer.

Hace ya muchos años, cuando formaba parte de Toastmasters, una organización internacional cuyos miembros aprenden y practican técnicas de comunicación en público y de liderazgo, tuve la oportunidad de formar parte de la mesa directiva que se integraba de siete personas: un presidente, un vicepresidente educativo, un vicepresidente de membresías y otros cuatro individuos con diferentes funciones. Yo asumí la presidencia del club y en la toma de protesta, el presidente saliente me dijo unas palabras que tienen mucho sentido cuando se trata de dirigir equipos de trabajo. El presidente saliente me dijo: “este es el momento en el que vas a tener que hacer todo lo que se tenga que hacer en el club, pero a través de la gente”. Más adelante pude observar como muchos presidentes de otros clubes empezaban muy bien, pero terminaban solos, haciendo mediocremente todo el trabajo que tendrían que hacer siete personas, pero ellos solos o con uno o dos ayudantes informales. Pero una posición de liderazgo no supone que el líder tenga que hacerlo todo el solo, sino que tiene que motivar, coordinar, dirigir y administrar para que cada miembro del equipo haga lo que le corresponde.

Durante mi gestión como presidente del club usé esa frase como un termómetro de mi liderazgo: si me encontraba haciendo lo que se suponía que otros tendrían que estar haciendo, entonces no estaba siendo el líder que debería ser, e inmediatamente empezaba a buscar las deficiencias en mi desempeño. Debo confesar que muchas de las deficiencias que encontré en mpi mismo no tenían que ver tanto con mis capacidades técnicas como con mi carácter o falta del mismo.

En mi trabajo como líder de proyecto también cometí ese error. Hace como quince años trabajaba con un equipo muy pequeño en el que tenía un practicante (estudiante de la carrera de ingeniería en sistemas haciendo prácticas profesionales) desarrollando una parte del sistema que teníamos que entregar. A la una de la tarde estábamos por salir a comer cuando me anunció el practicante que no podía terminar lo que íbamos a presentar a las tres de la tarde, justo después de comer. Al mismo tiempo se acercó otro desarrollador y me dijo que tampoco podía estar listo para la presentación. Me enojé mucho y empecé a cuestionar su desempeño. Los interrogué para saber dónde estaban encontrando las mayores dificultades y una vez que encontramos el problema me avoqué a resolverlo con mis propias manos. Les dije “Parense junto a mi para que vean cómo se hacen las cosas”. Los mantuve a cada uno viendo sobre mis hombros hasta que, diez minutos antes de la presentación, terminé todo el trabajo, probamos y todo funcionó correctamente.

Me levanté y les dije “no merecen estar en la junta de presentación de avances” y acudí a la junta yo solo. Afortunadamente todo salió bien: el usuario quedó complacido y mi coraje ya había desaparecido. Esa noche estuve reflexionando. Desde luego estaba orgulloso por mi desempeño técnico porque había resuelto en tiempo récord lo que dos desarrolladores no habían podido resolver, pero no estaba tan orgulloso por mi desempeño como líder. Por alguna razón los desarrolladores no pudieron cumplir con su tarea y yo no me enfoqué en darles la confianza y la oportunidad para ventilar eso. Claro que el tiempo estaba encima y no podía sentarme a hacerle al psicólogo mientras teníamos que entregar un resultado, pero también es cierto que no había motivado a esos muchachos últimamente ni había dado la oportunidad para discutir dificultades acerca de sus asignaciones.

Ese día terminé con una sensación de vacío que estaba tratando de llenar con falsos sentimientos de orgullo acerca de mi desempeño técnico. El vacío tenía que ver con una falta de liderazgo. Entregamos a tiempo, pero la relación con mis desarrolladores quedó desgastada, los humillé y no les ayudé en lo absoluto. Creía que ellos deberían aprender con la valiente hazaña que yo había hecho, pero estaba muy equivocado. Ese día me prometí no volver a meter las manos en el trabajo de otro colaborador, sino apoyarlo hasta que se alcanzara el objetivo aun que eso tomara más tiempo. Esto me obligaría a supervisar frecuentemente, a motivar, a involucrarme auténticamente. En muchas ocasiones posteriores los muchachos se acercaban e insinuaban que necesitaban el tipo de “ayuda” que les habría dado en el pasado (hacerlos a un lado y hacer la programación yo mismo), pero siempre les ofrecía un tiempo para hacer preguntas que los ayudaran a salir del ciclo mental en el que habían caído, hasta que empezaban a encontrar ellos mismos la solución. Al acercarme más a mi equipo pude entender mejor cuáles eran sus fortalezas y cuales sus debilidades y me enfoqué a ayudarles a superarlas con anticipación.3d-women-arrow-011-300×300.jpg

En una ocasión asigné un trabajo a una practicante y al poco tiempo se acercó y me dijo que no podía hacer el trabajo. La escuché y le di algunas ideas de como podía resolverlo y se fue contenta a intentarlo. Regresó unas horas después diciendo “ya lo intenté y no se puede”. Le pregunté qué es lo que esperaba que yo hiciera y ella me dijo “pues que se lo asignes a alguien más y me des a mí algo más fácil” a lo que yo le contesté “aquí no estamos en la escuela en donde muchas veces se premia el esfuerzo, éste es el trabajo y el trabajo se hace o no se hace, aquí no hay calificaciones de siete  u ocho, aquí es diferente”. Después le di otros consejos de cómo podría resolver el problema y se retiró muy pensativa. Mas adelante regresó diciéndome que mi sugerencia no funcionó, pero que intentó otras muchas cosas hasta que lo logró. Yo revisé el producto y realmente el problema estaba resuelto. Me sentí muy satisfecho por no haberle resuelto la situación; ella entendió que yo estaba para ayudarle, no para resolverle sus problemas, entendió que ella era responsable por dar un resultado, ella entendió que se le pagaba un sueldo por los resultados que diera y no por intentarlo. Ella estaba motivada y yo me estaba convirtiendo en el líder de proyecto que creía que debía ser.

La productividad no tiene que ser vista como la cantidad de cosas que haces, sino como los resultados que provocas para la compañía. Los resultados de un líder de un proyecto deberían ser medidos en su capacidad por hacer que los demás den resultados, por el nivel de liderazgo que demuestras, por tu capacidad de hacer que los demás hagan lo correcto, en el tiempo adecuado y con la calidad que se requiere.

Desde luego que los reportes de avance son necesarios, pero el liderazgo es mucho mas que eso. A veces hay que ser psicólogo, a veces adivino y, si el equipo lo necesita, a veces hay que “arriesgarse” a ser un amigo para ellos.

Por Fernando Valdez

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.