Por Dave Nielsen

Los veteranos gerentes de proyectos saben que aceptan la responsabilidad del proyecto cuando aceptan el rol de gerente de proyectos. También saben que la falta de autoridad puede obstaculizar seriamente su capacidad para cumplir con los objetivos establecidos para el proyecto. La responsabilidad es directamente proporcional a las consecuencias. La responsabilidad de los resultados del proyecto no significa que sean apartados hasta el próximo proyecto si el que están liderando falla, tiene una consecuencia monetaria. Sufrirán con el proyecto a través de la eliminación o reducción de bonificaciones, una reasignación a un rol menos responsable (con una reducción salarial correspondiente) o despido en el caso de los consultores.

La conexión entre la responsabilidad y las consecuencias está arraigada en los negocios. Los proyectos más grandes y costosos tienden a involucrar a gerentes de proyectos más senior y la consecuencia del fracaso será proporcional. También se intensificará la conexión entre los resultados del proyecto y las consecuencias. Lo que falta en mi experiencia (más de 20 años como gerente de programas y proyectos) es una correspondencia entre la autoridad y la responsabilidad. Los gerentes de proyectos pueden hacer gran parte de la planificación del proyecto sin tener acceso a la autoridad. Los gerentes de proyectos necesitarán ayuda de expertos en la materia para parte del trabajo de planificación, incluso si es solo para validar estimaciones de esfuerzo o costos. Los proyectos más grandes y complejos tienden a necesitar más expertos en la materia hasta el punto de que algunos de los trabajos son planificados por estos expertos. La autoridad necesaria para adquirir y gestionar los recursos necesarios para este trabajo generalmente vendrá con el territorio. Es cuando el proyecto llega a la fase de construcción o implementación que el gerente de proyectos necesita autoridad. Pueden planificar el trabajo, organizarlo y monitorear el rendimiento, pero sin autoridad, tienen una capacidad muy limitada para asegurarse de que el trabajo se realice a tiempo y con la calidad necesaria.

Los proyectos más grandes, costosos y complejos son liderados por gerentes de proyectos que ocupan puestos de alto nivel en sus organizaciones y aportan ese nivel de autoridad a sus proyectos. El proyecto Manhattan, que entregó la bomba atómica durante la Segunda Guerra Mundial, es un buen ejemplo de este tipo de proyecto y gerente de proyectos. Leslie Groves, quien dirigió el proyecto, era un general de 3 estrellas. La gran mayoría de los proyectos que no entran en la categoría del proyecto Manhattan en términos de tamaño son donde la conexión entre la autoridad y la responsabilidad se desmorona. La mayoría de los proyectos en la actualidad se ejecutan en un entorno “matricial” donde la organización utiliza gerentes de proyectos para ejecutar proyectos y gerentes funcionales para gestionar personas. El entorno matricial es adecuado para la mayoría de las organizaciones porque tienen una mezcla de trabajo operativo y de proyectos. El problema con el entorno matricial es que rara vez vienen con un plan para la división de autoridad entre el gerente funcional y el gerente de proyectos, lo que significa que el gerente de proyectos no tiene autoridad y el gerente funcional tiene toda la autoridad desde la perspectiva de los recursos. Las organizaciones con entornos matriciales más maduros pueden haber tomado algunas medidas para resolver los problemas que esta división causa, pero rara vez las definiciones de los 2 roles incluyen una descripción precisa de la autoridad. Esto se debe probablemente también al hecho de que el grupo de recursos humanos juega un papel importante en la definición de la autoridad a través de sus políticas y tienden a estar rezagados en la adaptación de sus políticas a la gestión de proyectos.

Los problemas comienzan con la adquisición del equipo del proyecto. Los gerentes de proyectos son propensos a la misma codicia que el resto de la raza humana y les gustaría tener plena libertad para adquirir los mejores recursos que la organización tiene para ofrecer. Los gerentes funcionales, por otro lado, tienen en cuenta sus responsabilidades operativas. Se les compensará por los recursos que ceden al proyecto, pero generalmente no se les incentiva para asegurarse de que sus mejores y más brillantes estén disponibles para el gerente de proyectos. Eso se debe a que su desempeño se mide en función del éxito de sus responsabilidades operativas. Si ponen a disposición de proyecto a sus mejores recursos, pueden no cumplir con sus metas y objetivos operativos y eso puede tener un impacto negativo en su compensación.

El enfoque más efectivo que he visto para equilibrar las necesidades operativas y de proyecto es tener gerentes funcionales cuya única responsabilidad sea el “cuidado y alimentación” de los recursos. Dado que no tienen otras responsabilidades operativas, son libres de evaluar las necesidades competitivas de los proyectos y las operaciones y tomar decisiones de asignación en función de su percepción de lo que es mejor para la organización.

Los problemas encontrados con la adquisición del equipo se propagarán a lo largo del resto del proyecto. Suponiendo que las estimaciones de esfuerzo y duración se basaron en algún nivel de rendimiento que es mayor que el que algunos de los miembros del equipo adquiridos son capaces de cumplir, el rendimiento del proyecto sufrirá. Señalar al patrocinador del proyecto que los problemas de rendimiento son causados por miembros del equipo que no cumplen con las expectativas puede o no aliviar la situación. Es probable que el patrocinador vea su queja con escepticismo si no planteó el problema antes. La incapacidad para realizar el trabajo no es la única causa de un mal rendimiento. Con mucho, la causa más común de un rendimiento inadecuado es la pérdida de tiempo de los recursos debido a demandas operativas. Las demandas pueden ser legítimas y el trabajo operativo exigido al recurso puede ser el mejor uso posible de ese recurso para el bien de la organización. Eso no ayuda al gerente de proyectos cuando tiene que explicar un mal rendimiento del proyecto a las partes interesadas. Esta situación es lo suficientemente mala cuando el gerente de proyectos recibe aviso de la demanda, pero es mucho peor cuando se entera del cambio después del hecho. El nivel de autoridad que se le ha dado al gerente de proyectos, o al menos la percepción del gerente funcional de esa autoridad, a menudo determinará si se entera del trabajo operativo antes o después del hecho.

El otro lado de la moneda de los recursos es el reconocimiento y las recompensas que se utilizan para construir el ánimo del equipo. La falta de autoridad en esta área generalmente tiene que ver con la capacidad del gerente de proyectos para gastar dinero en premios o comprar cualquier otra actividad de construcción de equipos. El reconocimiento y las recompensas generalmente están gobernados por la política de recursos humanos, que es la razón por la cual al gerente de proyectos no se le da autoridad para otorgar estos a los miembros del equipo que lo merecen. La falta de un presupuesto para comprar premios es la otra razón. Por último, el gerente de proyectos puede ser llamado a lidiar con miembros del equipo cuya cabeza simplemente no está en el juego. Tienen la capacidad, experiencia y capacitación para realizar el trabajo al nivel de competencia previsto en los planes del proyecto, pero no lo hacen. Puede haber una variedad de razones para esto, pero generalmente se derivan del compromiso del recurso con el proyecto, o la falta de él.

Veamos el ejemplo de un proyecto de mejora de procesos para ilustrar lo que quiero decir. El beneficio de la mejora de procesos es la eliminación de esfuerzo, lo que se traducirá en la pérdida de empleo (al menos en ese departamento). Algunos de los miembros del equipo que trabajan en este proyecto pueden ser aquellos cuyos empleos serán eliminados; después de todo, son los expertos en la materia en el antiguo proceso. ¿Es razonable esperar que estas personas muestren entusiasmo por el proyecto? Por supuesto que no. A menos que el gerente de proyectos pueda mostrar a estos miembros del equipo cómo el proyecto les beneficiará, o al menos no les perjudicará, serán menos comprometidos con los objetivos del proyecto. La falta de entusiasmo puede no tener nada que ver con la seguridad; hay muchas razones por las que un miembro del equipo puede no dar su mejor esfuerzo al proyecto: celos, la percepción de que sus mejores intereses se sirven si el proyecto falla, un compromiso con un proyecto que perciben como competencia, la insatisfacción de que un amigo no está asignado al equipo, son solo algunas de las razones “políticas” por las que un miembro del equipo puede no dar su mejor esfuerzo al proyecto. Resolver cualquiera de estos problemas requerirá que el gerente de proyectos tenga cierto grado de autoridad sobre el recurso. Esto no necesariamente significa que tengan autoridad para contratar y despedir, la capacidad de influir en su compensación puede ser suficiente.

Ahora que he presentado el caso de una autoridad acorde con el grado de responsabilidad, veamos algunas formas y medios de adquirir esa autoridad. Comenzaré abordando a las personas que patrocinan proyectos. Debe responsabilizar a sus gerentes de proyectos por los resultados del proyecto; ese es su trabajo, pero no tiene sentido responsabilizarlos sin darles la capacidad de cumplir con los objetivos y metas del proyecto, y la autoridad es un componente clave de esa capacidad. Puede ayudar aquí llegando a un acuerdo con su gerente de proyectos sobre el grado de autoridad que le está dando. Trabajando dentro de las políticas dictadas por su grupo de recursos humanos, debe asignarles el nivel de autoridad que ambos acuerden que necesitan. No hable en generalidades, sea específico. El gerente de proyectos debe saber cuáles son sus remedios en caso de tener problemas de rendimiento con los miembros del equipo. El proceso utilizado para determinar la composición del equipo del proyecto también debe ser claramente articulado. ¿Cómo se resolverán las discrepancias sobre los recursos individuales? Por supuesto, para hacer esto de una manera que tenga sentido para su organización, deberá priorizar su proyecto en comparación con los otros proyectos y trabajos operativos de la organización. Si los objetivos y metas del proyecto son de alta prioridad, el proyecto no puede ser de baja prioridad cuando se trata de competir por recursos escasos. Su nivel de autoridad sobre los miembros del equipo, una vez que se haya definido el equipo, también debe ser claramente articulado. ¿Cómo manejará el gerente de proyectos a un miembro del equipo cuyo rendimiento es deficiente porque no tiene las habilidades o experiencia necesarias? ¿Cómo manejarán al miembro del equipo que tiene las habilidades y experiencia necesarias pero no está rindiendo por alguna otra razón? La autoridad del gerente de proyectos debe ser articulada con suficiente detalle para que estas preguntas sean respondidas.

Delegar autoridad al gerente de proyectos no tiene por qué contravenir ninguna política de recursos humanos. Por ejemplo, puede ser contrario a la política permitir que el gerente de proyectos contrate o despida recursos, pero donde los interesados, los clientes y otros, contribuyan a las revisiones de rendimiento, asegúrese de que el gerente de proyectos sea un contribuyente y asegúrese de que su revisión se pondera de acuerdo con la cantidad de tiempo que el recurso pasa en el proyecto y la prioridad del proyecto. Por otro lado, a veces los proyectos son lo suficientemente importantes y las políticas de recursos humanos lo suficientemente flexibles como para justificar cambios. No tenga miedo de reunir aliados políticos y presentar el caso de cambio a recursos humanos. Puede tener éxito en efectuar el cambio para el próximo gran proyecto, incluso si no tiene éxito en hacer el cambio para el proyecto actual.

El área del proyecto para la que el gerente de proyectos necesitará autoridad es el reconocimiento y las recompensas. El gerente de proyectos debe poder articular un programa de reconocimiento y recompensas para el proyecto, o cómo utilizará los programas de reconocimiento y recompensas existentes. Asegúrese de que tengan suficiente autoridad para administrar el programa. Esto significará un presupuesto, en la mayoría de los casos. Determine cómo hará que el dinero esté disponible cuando sea necesario en casos en los que sea imposible darle al gerente de proyectos alguna autoridad de firma. Por último, asegúrese de estar disponible para participar en ceremonias de premios o actividades de construcción de equipos. No he tratado con ningún patrocinador que no haya disfrutado de estas ocasiones una vez que las haya experimentado.

Los gerentes de proyectos que tienen patrocinadores que no han leído lo anterior, o que no se sienten cómodos tomando la iniciativa con usted, deberán iniciar la conversación ellos mismos. Una vez que haya definido el nivel de autoridad que necesita en detalle, asegúrese de que esté documentado. Si su autoridad no está escrita en ningún lugar, no la tiene. La memoria de las personas es lo que es, la percepción que tiene de la autoridad que tiene diferirá de la de su patrocinador y esa brecha solo se ampliará con el tiempo a medida que las memorias se deterioren. Recuerde que la autoridad que se le da no se saca de la nada, es la autoridad que su patrocinador tiene (o cualquier otro stakeholder senior) y que le delega a usted. Su autoridad debe estar capturada en la Carta del Proyecto. El nivel de detalle no necesita ser mayor que el resto de la carta; puede dejar eso para tareas o propósitos específicos. Debe estar especificado en generalidades como “el Gerente de Proyecto tiene la autoridad para participar en la selección del equipo del proyecto”, “el Gerente de Proyecto evaluará a los miembros del equipo y estas evaluaciones se utilizarán en las revisiones de rendimiento” o “el Gerente de Proyecto tiene la autoridad para abordar problemas de rendimiento”. Los detalles específicos se pueden dejar hasta que el proyecto avance a la etapa en la que se necesite autoridad. Por ejemplo, puede solicitar un correo electrónico del patrocinador antes de la adquisición del equipo que especifique cómo se tomarán las decisiones sobre los miembros individuales del equipo y cómo se resolverán las disputas. La autoridad es como un músculo: se atrofiará si no se usa y no estará disponible cuando más se necesite. Su patrocinador le ha dado autoridad para que la use para lograr los objetivos y metas de su proyecto, por lo que nunca debe dejar de alcanzarlos debido a la falta de autoridad a menos que se le haya negado específicamente. Esto significa que cuando los miembros del equipo se nieguen a reconocer su autoridad para dirigir su trabajo, debe usarla para imponer su voluntad sobre ellos. No confunda la imposición de su dirección con el abuso. Abusa de su autoridad cuando la usa para fines distintos al logro de los objetivos y metas del proyecto o cuando muestra favoritismo imponiendo consecuencias o recompensas. Evite abusar de su autoridad a toda costa, pero no a costa de dejar de ejercerla. Para asegurarse de evitar abusar de su autoridad, es una buena idea tener a mano las políticas y pautas de recursos humanos y asegurarse de estar familiarizado con ellas.

Los gerentes de proyectos que inician la conversación sobre la autoridad tendrán la ventaja de poder definir el nivel de autoridad que creen que necesitan. Esto se puede hacer al especificar su autoridad en la versión preliminar de la Carta del Proyecto o en algún otro documento que la preceda. No sea tímido aquí. Es mejor tener autoridad que no necesita y no usa que no tenerla y necesitarla. No tenga miedo de ejercer una autoridad que no tiene porque usted ni el patrocinador previeron la necesidad de ella. Es mucho más probable que su patrocinador le perdone por ejercer una autoridad que conduce al logro de un objetivo que si no ejerciera la autoridad y no lograra el objetivo.

La mayoría de lo que he dicho aquí se aplicará a los gerentes de proyectos que son empleados permanentes de las organizaciones para las que gestionan proyectos, pero ¿qué pasa con los consultores? Estas personas se encuentran perpetuamente en entornos “matriciales” porque incluso en organizaciones que están proyectizadas o que tienen un arreglo matricial maduro y probado, no se aplican al consultor. Los consultores deben ser especialmente diligentes al describir su nivel de autoridad y al usarlo. Su autoridad nunca incluirá la capacidad de despedir o elegir recursos al adquirir el equipo. Como máximo, tendrán la autoridad para contratar contratistas y participar en negociaciones de adquisición de empleados, por lo que deben asegurarse de tener un recurso que aborde un problema insoluble con un miembro del equipo. No olvide que cuando llega por primera vez al trabajo, es una cantidad desconocida para los interesados. Es posible que hayan tenido exposición a usted cuando entrevistó para el puesto, pero aún es una cantidad desconocida. Después de haber estado en el puesto por un tiempo, debería haber ganado un nivel de confianza que le permitirá más margen de maniobra para ejercer la autoridad, pero hasta entonces no haga suposiciones que puedan avergonzar a su patrocinador.

Finalmente, si no logra que su patrocinador le delegue la autoridad que necesita para tener éxito, asegúrese de documentar ese hecho. ¿Cómo lo hace sin insultar a su patrocinador? Simple, no tener la autoridad necesaria para lograr los objetivos y metas del proyecto es un riesgo para esos objetivos y metas y debe registrarse en el registro de riesgos del proyecto. No describa estos riesgos en términos personales; descríbalos en términos de cómo se ve el evento de riesgo y el impacto probable en el proyecto si ocurren. Una conversación sobre estrategias de mitigación para abordar el riesgo puede llevar a otorgarle la autoridad. Al menos deberían llevar a una estrategia de mitigación que reduzca el nivel de riesgo. Si todo lo demás falla y no se otorga autoridad ni se identifican estrategias de mitigación aceptables, el proyecto debe aceptar el riesgo. Aún tiene la opción de revisar este riesgo y su aceptación cada vez que se revisa el registro de riesgos con los interesados. Una palabra de precaución aquí: el riesgo identifica un desacuerdo entre usted y su patrocinador; no use esto como una oportunidad para avergonzar a su patrocinador frente a sus compañeros o gerentes.

Una última palabra de consejo para todos los gerentes de proyectos: generalmente es más fácil pedir perdón que permiso. Cuando tenga dudas, asuma la autoridad y ejerza. Si ha sobrepasado sus límites pero ha logrado su objetivo, su patrocinador puede señalarle el error, pero no estará tan insatisfecho con el resultado como lo estaría si no ejerciera la autoridad y no lograra el objetivo.

Dave Nielsen es un principal de Three O Project Solutions, los proveedores de AceIt©. Dave también fue el arquitecto clave responsable de la creación del producto. AceIt© ha preparado a gerentes de proyectos de todo el mundo para aprobar sus exámenes de PMP®. Puede encontrar testimonios de algunos de sus clientes en el sitio web de Three O (http://www.threeo.ca/).