Enhorabuena, ya tienes asignado un proyecto y el orgullo de ser un Jefe de Proyecto no te quita nadie. Celébralo ahora y prepárate justo después que viene una ola de hostias de campeonato. Una pastilla de aspirinas y buena preparación puede que eviten que tu estado anímico recaiga con la misma rapidez de un bipolar.

Una de las primeras cosas es hacer que el cliente ya no hablo de tu propia empresa entiendan cuál es tu rol en el proyecto. Algunos, no especialmente familiarizados con el concepto de gestión pueden erróneamente atribuirte tareas que no te corresponden, generando así expectativas que seguro que no podrás cumplir.

Una llamada al Cliente, sus contactos técnicos y/o de gestión, claro está si no tienes un project manager al otro lado puede evitar muchas decepciones.

Una buena agenda para esta llamada podría ser:

• Explicar tu Rol en el proyecto
• Habla sobre tu propio background y experiencia en la Gestión de Proyectos
• Habla sobre la función de jefe de Proyecto (9 Áreas de Gestión de proyecto)
  • Integración – Cumplimiento de Metodología e integración del resto de áreas de conocimientos.
  • Alcance - Planificación de proyecto desde perspectiva de alcance (lo que se va a hacer y lo que no se va a hacer en el proyecto)
  • Tiempo - Control de línea de tiempo, entregas, entregables y plazos.
  • Coste - Control de línea de costes, valor acumulado, etc.
  • Calidad - Control y aseguramiento de calidad en todo el proceso interno y externo del proyecto.
  • Recursos Humanos - Organización y distribución de trabajo para todo el equipo de desarrollo (menciona el número de personas involucradas).
  • Comunicación – Gestión de expectativas, reporting, vamos el 90% de tu tiempo.
  • Riesgos – Gestión de los riesgos, calificación y diseño de planes de contingencia y estrategias de mitigación.
  • Aprovisionamiento y adquisiciones - Aprovisionamiento y gestión de infraestructura necesaria para el proyecto. Compras y Gestión de contratos, etc.

Toda la charla es difícil de tragar y asimilar, así pues para terminar resume tus objetivos. Por ejemplo: Mi propósito es asegurarme de que el proyecto se entrega según el alcance definido, dentro de las limitaciones de coste y en plazo.

A continuación sería conveniente ofrecerle al cliente la oportunidad de preguntar por si tiene alguna duda que puedes aprovechar para reforzar tu mensaje inicial.

Luego si lo/la ves receptivo deja claro los siguientes puntos:

• Todo lo que tiene que ver con la gestión del proyecto (tiempo, alcance, coste, recursos, logística) es necesario tratar con el PM ya que si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia afecta a las demás.
• Si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia yo debo estar informado y autorizar y controlarlo.

Espero que la llamada vaya bien y que el cliente cuelgue con una clara idea de lo que un PM es, qué puede hacer y para qué sirve.

El “poder duro” y el “poder blando” son caras de la misma moneda, atributos o tipologías de un fenómeno sociológico a las órdenes de líderes, políticos, empresarios, jefes de proyecto, ciudadanos corrientes que diariamente, sin darse cuenta de ello, intentan alterar la realidad que les rodea a su favor.

El “poder duro”, asociado normalmente con la agresividad, a través de medidas de coerción, ejercicio de fuerza y amenaza de castigo, es un término clave en muchas de las teorías de realismo político y estrategias de negociación en proyectos. Teorías históricamente relevantes al concepto de poder ya que enfatizan la codicia de algunos negociadores de conseguir la situación de ganancia, dominación, sin considerar siquiera la posibilidad de llegar a un win-win. Esta vía de lograr los objetivos requiere fuerza física, acceso a recursos y a medida de que los interlocutores evolucionan en su conocimiento y experiencia, rara vez resulta eficaz a largo plazo y puede suscitar una respuesta inesperada (e.g.: rotura de negociaciones y situaciones lose-lose). Sin embargo, existen situaciones cuando el uso de “poder duro” es la única vía para alcanzar el objetivo.

Mientras que el “poder blando”, un instrumento igualmente afilado en manos de un project manager apto, sirve para conseguir los mismos objetivos pero mediante diálogo, convencimiento, negociación e incluso manipulación. El empleo provechoso de poder blando depende de otras restricciones, tales como capacidad de comunicación, carisma personal, credibilidad y autoridad aunque a veces puede confundirse con debilidad. El “poder blando” difícil de utilizar per se, a diferencia del “poder duro” muy pocas veces resulta suficiente, salvo excepciones. Una forma efectiva de conseguir nuestros objetivos políticos en el proyecto es combinar las características comunes y las diferencias de ambas técnicas coactivas vistiendo "la mano de hierro” con “un guante de terciopelo”.

El reto de los managers de hoy es saber medir la cantidad de ambos ingredientes y combinarlos para conseguir el “poder inteligente”, menos invasivo, menos dependiente de recursos y más diplomático. Para concluir, los dos tipos de poder son simples medios para conseguir un fin, los dos pueden ser igualmente poco humanitarios y utilizados de forma independiente su eficacia a veces es limitada. Cada uno de los poderes tiene sus propias características únicas y limitaciones: el “poder duro” es intensivo en uso de recursos, perseverancia, requiere fuerza física y se materializa a través de agresión; el “poder blando”, a su vez más difícil de usar, precisa dones de comunicación, carisma personal, credibilidad y diplomacia entre otras cualidades.

Referencias:

• Joseph S. Nye Jr., 2008, “El próximo líder estadounidense” (PDF), Project Syndicate.
• Jack Donnelly, 2000, “Realism and International Relations”, Cambridge University Press.
• Joseph S. Nye Jr., 2004, “Misuses of Power: Causes and Corrections”, Compass: A Journal of Leadership.
• Alexander Moseley, 2006, “Political Realism – The Internet Encyclopedia of Philosophy”, URL.
• Joseph S. Nye Jr., 2006, “Soft Power Is Cultural Power”, Foreign Policy, 1 March 2006.

Dentro del equipo de proyecto se encuentran muchas personas: el Sponsor, el Project Manager, Staff, los asistentes y técnicos, sin contar a otros stakeholders externos como el Cliente, los proveedores, los auditores de calidad y los responsables de seguridad. El mantenimiento de canales de comunicación entre tantas personas puede ser una tarea tediosa que no tardará en afectar la marcha del esfuerzo como tal si es ignorada. Por ejemplo, si tenemos 10 stakeholders que deben estar informados en todo momento sobre lo que sucede en el proyecto, el número de canales de comunicación con los que debemos lidiar serían 45 (la fórmula para calcularlo sería n(10-1)/2), por lo que podemos hacernos la idea del enorme crecimiento del esfuerzo que supone la comunicación diaria en proyectos. La claridad del Plan de Comunicación, una herramienta válida y utilizada para la designación de canales de comunicación con stakeholders, es a veces es ignorada en el ámbito de comunicaciones internas, tanto en proyectos de desarrollo de software, así como en cualquier otro sector sea la obra civil, bioingeniería, construcción, etc. El Project Manager actúa de interfaz principal con las personas externas, siempre según la Responsibility Assignment Matrix (RAM) y el Plan de Comunicación, pero sucede con frecuencia que no se le otorga la debida importancia a las comunicaciones internas, dentro del equipo del proyecto, sea por falta de tiempo, carga de trabajo o el tamaño del equipo de proyecto. Los fallos de comunicación internos a veces suelen ser los causantes de grandes malentendidos dentro del mismo equipo de trabajo y a largo plazo pueden causar un “burn-out” innecesario y doloroso que afecta al rendimiento del equipo en el proyecto en general y en la última instancia influir negativamente los resultados de la empresa. Seguramente hay muchas soluciones que resolverían o actuarían de Acción Preventiva para ese tipo de situaciones. Éstas van desde la frecuente actualización del Plan de Comunicación, uso de entornos colaborativos dinámicos de tipo blog (Sharepoint, Confluence, Wiki, etc.), trainings de cohesión de equipo, etc. … “De todas estas alternativas la que mejor podría funcionar en muchos casos es la combinación de varias: un riguroso seguimiento documental, la continua actualización de Planes de Comunicación, la permanente revisión de la Matriz de Responsabilidad y, por último, la incorporación de las nuevas técnicas de colaboración dinámica en los grupos de trabajo”… Esta es la opinión profesional de varios de los PMP’s que participaron en el Congreso Global PMI 2006 en Madrid. Las primeras medidas institucionalizan los procesos de comunicación y las últimas permiten un intercambio rápido e informal de datos entre los miembros del equipo en todo momento. Un ejemplo práctico sería que un Director de Proyecto, tras mantener una reunión con un Cliente, desde su portátil o incluso una BlackBerry, apuntara rápidamente los puntos más cruciales de la reciente reunión en el blog del proyecto. Así ese ejercicio no únicamente le serviría al PM para plasmar cuanto antes las notas de la reunión mientras que las tengas "frescas", sino también permitiría a los miembros del equipo del proyecto estar informados de primera mano sobre el contenido de la reunión, incluso antes de que se elabore el acta formal.

Aparte de las dificultades habituales de cualquier proyecto y bajo un inocente velo de transparencia, a veces el equipo de gestión se empeña en trasladar a los miembros del equipo de producción (desarrollo, fabricación, construcción, etc.) toda la información de la que dispone a medida de que le va llegando lo que puede crear en los participantes preocupaciones innecesarias, si los datos no se distribuyen de forma adecuada. Transparencia como política de gestión, sin ninguna duda, es algo positivo pero introduzcamos una variable más – la llamada "need to know". Un criterio para decidir quién debe saber qué y para qué. En los equipos cada uno sabe exactamente el labor que le corresponde (o por lo menos debería). Es el rol de del Project Manager y sus asociados decidir a quién se le debe proporcionar la información, de qué manera y con qué fin. Es allí Donde entra en el juego la matriz de comunicaciones, un documento "vivo" que muestra cómo debería fluir la información en el proyecto. Complicaciones a nivel político, quejas, comentarios de clientes o proveedores deben ser previamente evaluados y dirigidos de forma controlada a los que necesitan y pueden actuar en beneficio del proyecto al disponer de la información.

Las iniciativas que requieren participación de un cierto número de personas sea en local o distribuidos geográficamente necesitan que estos grupos desarrollen un sentimiento de pertenencia al grupo y comprendan exactamente el objetivo del proyecto y los entregables a producir. Para esta tarea desde hace algunos años, al principio sólo en el sector de construcción e ingeniería, se utilizaban war-rooms, centros de guerra (traducción libre), dónde los participantes tenían a su plena disposición y fácil accesibilidad toda la documentación del proyecto a la vista. Allí se reunían, discutían y pensaban sobre como resolver los problemas, y también celebraban el éxito. Para proyectos de software el warroom debería tener posteado en la pared los diagramas WBS y el PERT, en sus últimas 2 versiones para ver los cambios que se realizaron. Para facilitar el entendimiento el WBS dictionarry también debería figurar allí mismo. Es buena idea postear el registro de riesgos con sus planes de mitigación y contingencia. Ese espacio dedicado al proyecto no es fácil de mantener si tenemos equipos distribuidos por todo el mundo por lo que disponibilidad de una intranet con los mismos datos en formato Wiki puede ser una válida alternativa.

En equipos multidisciplinares dónde personal de proyecto tiene que estar encargado de dar soporte a determinados equipos de terceras empresas pueden surgir relaciones informales que pueden llegar a sustituir un proceso formal de aprobación de cambios. Cambios alcance se comentan en la máquina de café. El cliente prefiere comentarlo con alguien con alguien que no le va a decir que "no" o derivarlo a CCB, por lo tanto evita el canal oficial de comunicación Cliente – Project Manager. En caso de que miembros del project management team no hayan derivado la petición al PM y ésta se ha realizado se produce un scope creep que llevará más adelante el proyecto al desastre. El cliente informa sobre no conformidades con requerimientos, descontento y acusa al equipo de proyecto de que el producto entregado "no funciona". Es por ello que necesitamos realizar el mantenimiento de canales de comunicación no solo con nuestro equipo sino también con el del cliente.

La gestión de proyecto aparte de ser un conjunto de prácticas para conseguir un objetivo único a partir de unas restricciones y recursos limitados es una continuación de nuestras relaciones personales con proveedores, clientes y partners. En el trabajo que se desarrolla en equipos virtuales donde MSN, Skype, o ICQ son herramientas principales de comunicación las confusiones están a la orden del día, de allí nerviosismo, preocupación y posibles sentimientos de que el trabajo trascurre más despacio de lo que debería. En todo el fallo de comunicación esta presente el factor del "colchón" que tenemos de confianza con la persona que hablamos, si ese margen es suficiente – existe confianza y los problemas suelen solucionarse con mayor facilidad. Cuanto menos confianza a nivel personal hay los conflictos más insignificantes suelen trascender increíblemente en montañas. Para crear ese colchón de confianza con gente que no lo ve todos los días es difícil. Siempre será necesaria alguna visita, estar charlando a menudo amigablemente sobre alguna tontería, preocuparse a nivel personal sobre los asuntos de esa persona, compartir experiencias.