archivo

Archivo de la etiqueta: jefe de proyectos

Una objetivo fundamental de un jefe o gestor de proyectos, Scrum Master o cualquiera que sea el nombre que queramos darle, es la de tratar de conseguir un contexto lo más estable posible que permita que todas las partes involucradas en el proyecto desempeñen su función de la manera más eficiente posible.

Además del trabajo sobre el contexto que va más sobre líneas generales del proyecto: relación de confianza, gestión adecuada de expectativas, del valor ganado y de la inversión realizada hasta el momento, etc…, en el día a día del proyecto existen contingencias que pueden afectar al rendimiento del equipo de proyecto y que conviene solucionar cuanto antes para que el impacto sobre la productividad y los resultados sea el menor posible.

Está claro que un facilitador eficiente hace mucho bien al proyecto, parece un trabajo fácil pero no lo es en absoluto porque tiene mucho de inteligencia emocional, ya que para resolver esos problemas del día a día o para tratar de mantener un equilibrio en el proyecto se requiere mucha interacción y comunicación con otras personas que probablemente tengan unas prioridades y objetivos diferentes a los del equipo de proyecto.

Cuando el facilitador lo hace bien, las personas que trabajan con él tienden a despreocuparse de la resolución de determinadas contingencias que perfectamente podrían resolver ellos y/o el propio facilitador con el objetivo de que el equipo esté centrado en su trabajo decide asumir que toda la intendencia del proyecto pase por él.

Esto puede llegar a convertirse en un antipatrón por varios motivos: el facilitador se puede terminar convirtiendo en un cuello de botella, si el facilitador por el motivo que sea no puede dedicar tanto tiempo al proyecto se necesitará que los desarrolladores den un paso al frente para resolver estos problemas y/o para tratar de que el equipo siga gestionándose de manera adecuada pudiendo darse el caso de que no se encuentren preparados para realizar esas tareas o no las consideren de la suficiente importancia, degradándose paulatinamente el rendimiento y productividad del equipo impactando directamente en los resultados.

¿Cómo medir si un gestor está haciendo bien o mal su trabajo?, ¿tal vez el nivel de rentabilidad de sus proyectos?, ¿su nivel de ventas?, ¿el grado de aceptación por parte de las personas que trabajan con él?.

Se nos pueden ocurrir muchos indicadores. A mi hay uno que me parece muy interesante y es que un buen gestor debe solucionar muchos más problemas que los que crea. Evidentemente habría que complementarlo con otros indicadores para formar una opinión con más perspectiva, pero no por ello deja de ser algo sobre lo que se debe reflexionar.

Entrar como un elefante en una cacharrería, actuar a destiempo y/o de forma desmedida (o no actuar), tomar decisiones sin tener una visión clara del problema, tomar decisiones sin tener en cuenta el contexto, no contar con la opinión de tu equipo, mirar solo por tus intereses profesionales en lugar de tener una visión más general, no dar importancia al cliente, etc… son situaciones, decisiones o conductas que pueden dar lugar a la creación de problemas donde no existen o agudizar los ya existentes.

Decía Milt Bryce que: “Si viviéramos en un mundo perfecto, no sería necesario la existencia de gestores; los proyectos se ejecutarían en tiempo y coste. Sin embargo, la realidad es que vivimos en un mundo imperfecto”.

Para mi el objetivo principal de un gestor es que el equipo tenga claro que el objetivo es que como consecuencia del proyecto el cliente y/o el usuario estén satisfechos con él de manera que se hayan satisfecho sus expectativas, respetando que nos encontramos dentro del ámbito de una organización cuyo objetivo es obtener beneficios a través de los servicios que ofrece.

Ahora bien, este objetivo resulta utópico de conseguir cuando las condiciones de partida de un proyecto no se adaptan a las exigencias del mismo (proyecto infravalorado en esfuerzo y/o en tiempo y/o no compatible con las expectativas de calidad). Si se parte de un Death March Project o de una situación próxima a él, el gestor tendrá muy complicado mantener un discurso coherente porque cuando la manta es demasiado pequeña solo da para taparse la cabeza o los pies.

De la misma forma, si aún comenzando el proyecto con unas condiciones favorables, a lo largo de su desarrollo se producen contingencias que afectan sensiblemente a su ritmo, de manera que se requiere invertir un mayor esfuerzo en tareas que no lo requerían (cambios en procesos, sucesivas vueltas a atrás de funcionalidades por problemas en la especificación por parte del área usuaria, etc…), nos podemos encontrar en una situación parecida a la de si las condiciones de partida hubieran sido desfavorables.

¿Cómo mantener entonces ese discurso en el equipo? Soy de la opinión de que ese discurso debe mantenerse inmutable pero sin obviar la realidad en la que nos encontramos. El objetivo del equipo debe ser el mismo pero modulado a través de los discursos disponibles.

Es decir, el equipo tiene que ser productivo (acorde a sus posibilidades) e intentar minimizar errores evitables, por otro lado hay que intentar consensuar con el usuario una solución que sea lo más simple posible sin que éste vea perjudicada sus expectativas, además de tener muy cerrados los compromisos del usuario con respecto al proyecto, así como las medidas a tomar en el caso de que los errores o cambios sean debidos como consecuencia de los usuarios (estas dos últimas características deben estar bien resueltas en la fase de negociación, de lo contrario lo que puede ser una venta mala o muy mala se puede convertir en una venta nefasta).

Lo anterior no funciona siempre, es más, no funcionará en muchos casos, porque el cliente se aferrará con fuerza al contrato. Cuando no sea posible llegar a un acuerdo, cuando el cliente no entienda que puede ser más beneficioso tener un producto con las funcionalidades esenciales bien implementadas que un producto final donde casi nada funcione como debería, poco podemos hacer más allá de intentar llegar lo más lejos posible con los recursos disponibles (en el fondo hemos intentado alcanzar las expectativas del usuario aunque nos hayamos quedado a medio camino, respetando también en segundo término las expectativas de nuestra organización respecto al proyecto).

Cuanto más confíe el cliente en nuestro trabajo más entenderá lo que le estamos pidiendo y más dispuesto estará a hacer concesiones. La confianza es también resultado de la coherencia, es decir, no podemos pedirle al usuario que corra con sus errores si nosotros no corremos con los nuestros (y en este caso quien suele mirar por el ancho del embudo suele ser el proveedor).

Por tanto, el objetivo principal del gestor es mantener en el equipo el compromiso de entregar un trabajo de calidad y realizar las actuaciones oportunas para que el contexto del proyecto sea el más favorable posible para conseguir ese objetivo.

El gestor por tanto, es un facilitador, un dinamizador, es alguien que debe estar a disposición del equipo para que éste puede desempeñar su trabajo de la mejor forma posible, para ello debe ser alguien próximo al equipo, alguien dispuesto a sacrificarse y a ayudar, alguien quien dentro de sus posibilidades pueda echar una mano extra al equipo si hiciera falta.

El gestor también debe tomar decisiones y algunas de ellas tendrán un importante desgaste personal. A nadie le resulta cómodo reprender actitudes y a nadie le resulta agradable tener que prescindir de personal, pero si se quiere mantener un equilibrio y solidaridad entre los miembros del equipo de proyecto, será necesario realizar ese tipo de actuaciones.

Entiendo que quien no esté acostumbrado a una gestión de proyectos de este tipo, se cuestione en muchas ocasiones el valor que aporta un jefe de proyectos. También incluso en aquellos casos donde el gestor esté más alejado del proyecto sería conveniente analizar si lo está realmente por una cuestión de actitud del mismo, por una política de su organización o por imposibilidad material al estar participando en demasiados proyectos a la vez.

Existe algo todavía peor que el jefe de proyectos o gerente por parte del proveedor tenga como objetivo encajar el máximo número de horas posibles reales e imaginarias en los diversos proyectos que gestiona, dejando en un segundo plano u olvidando (en la mayoría de los casos) el cliente, los usuarios y el producto y es que el jefe de proyectos del cliente también oriente su gestión a la contabilidad, de manera que solo importe ejecutar trabajo, dejando en un segundo plano y olvidando (en la mayoría de los casos) que lo importante no es ejecutar trabajo sino que éste sea efectivo.

Estamos ante otro antipatrón muy típico por parte de las empresas que realizan servicios TIC a terceros y podemos ver un par de ejemplos muy frecuentes en lo que nos lo encontramos:

- Se envían a realizar servicios al cliente, aunque sean pocas jornadas, a personas que no tienen ningún tipo de experiencia en el trato con el cliente y/o a personas que pueden ser excelentes profesionales pero que son de trato complicado.

Muchas empresas se olvidan de que las personas con las que trata el cliente son la imagen de la compañía por mucha marca que haya detrás. Por este motivo es necesaria, como poco, una formación mínima para todas aquellas personas que traten con clientes, además de seleccionar muy bien a quien encomendar este tipo de trabajos.

- En servicios de outsourcing en el cliente, donde la empresa o el gerente de turno los abandona a su suerte, descargando toda la responsabilidad en el equipo (y en su jefe de proyectos) y solo apareciendo en determinadas reuniones puntuales con clientes o para trasladar quejas del mismo (por regla general, sin escuchar a su propio equipo y sin analizar con una cierta objetividad la situación, provocando situaciones donde se produce, por ejemplo, el antipatrón “cantamañanas“).

Esta sensación de abandono quema mucho al equipo, es cierto que se puede hacer más fuerte y homogéneo ya que no les queda otra si quieren sacar el trabajo adelante, pero estar solos, sin que nadie escuche sus problemas, es complicado y todavía más cuando su esfuerzo generalmente no se ve recompensado ya que están prácticamente al margen de la empresa.

Este antipatrón describe un comportamiento que, desgraciadamente, es muy habitual en nuestro sector.

Está asociado al comportamiento de jefes de proyecto, de equipo, gerentes, etc… que son completamente permeables hacia el cliente o hacia sus superiores y después cargan contra su equipo en el caso de que reciban alguna queja, malestar o exigencia.

Todo esto sin tener un conocimiento adecuado del contexto y sin escuchar lo que tenga que decir su gente o no prestando atención a lo que le puedan contar.

Tiene algunos aspectos en común con el antipatrón “abracadabra” con la diferencia principal de que en este se llega mucho más lejos.

Tal vez actuando de esta forma puedas apagar un fuego pero al final te terminarás quemando. No puedes gestionar en contra de tu equipo. Tu equipo tiene que estar respaldado, creer y confiar en ti.

Nos encontraríamos ante una situación concreta del antipatrón “responsable ausente“. En este caso, el gestor a modo de sortilegio establece una líneas generales para el desarrollo del proyecto y desaparece, apareciendo solo cuando existen problemas en el proyecto y generalmente como reacción ante las quejas de uno o más stakeholders (antipatrón “gestión dirigida por disparos“).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.211 seguidores