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.

Las 35 horas semanales franceses dan para más que los 40 españoles. He observado en caso de consultoras clientes y proveedores que programadores, managers y analistas hacen horas extra, se quedan hasta las tantas, sin embargo los proyectos no experimentan boosts de rendimiento ni avances significativos. Observada esta tendencia desde hace años las empresas consultoras han introducido un sistema de registro de horas que les permitiría conocer en qué invierten sus efectivos estas preciosas horas laborables durante el día. Al principio las iniciativas de registro de horas, ledger o nombres similares parecían una forma de control y lo son pero no es su único objetivo. Además de poder saber horas reales invertidas por proyecto versus horas estimadas, llevar acabo contabilidad de costes u optimizar el uso de recursos, es una herramienta inestimable incluso para los que la tienen que cumplimentar todos los días. Teniendo un todo list integrado en herramientas de registro permite a los miembros de equipo del proyecto hacer tangible su propio trabajo y eso para el PM le facilita la contabilidad de valor acumulado del proyecto y tareas de reporting. Las herramientas sin metodología adecuada no sirven para nada, sin embargo, conociendo las herramientas adecuadas para empresas medianas y pequeñas el aprender a usarlas puede forzar la implantación de ciertos conceptos metodológicos. Las siguientes herramientas pueden ser un buen punto de partida:

• Achievo (http://www.achievo.org) – Registro de horas y timesheet, buena madurez, open source.
• Replicon Timesheet (http://www.replicon.com/) – Registro de horas, timesheet, gastos, buena madurez, software comercial.
• Journyx Timesheet (http://www.journyx.com/) – Idem, software comercial, pero tiene versión limitada a 10 usuarios gratuita.

Feedback bienvenido.

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.