El lado humano de la gestión de proyectos

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Es consultor independiente en Dirección de Tecnologías de la Información y Gestión de Proyectos TIC, profesor de Sistemas de información y dirección de las TIC de la UOC y autor de artículos y libros sobre estas materias. A lo largo de su carrera profesional, ha alternado la actividad entre el sector privado y el sector público como directivo y consultor. Ha sido ejecutivo de empresas internacionales de servicios de sistemas de información y gerente de organización y sistemas de información en diferentes servicios públicos. Es licenciado en Filosofía y Letras, PDG del IESE y cuerpo técnico de la Seguridad Social. Su último libro es Gestión de proyectos informáticos: métodos, herramientas y casos, publicado por la editorial UOC.

PID_00215827
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

A lo largo de este material hemos ido presentado una disciplina nueva para muchos, la gestión de proyectos, poniendo un empeño especial en marcar las distancias con las metodologías de construcción y despliegue de cada producto o servicio TIC específico que, según hemos presentado, se integran dentro de la etapa de ejecución. El proyecto empieza antes y acaba después y comprende muchas más acciones.
El segundo mensaje que deseamos que el alumno retenga es que los proyectos TIC tienen que ver, normalmente, con oportunidades y problemas de negocio que el cliente desea resolver y no con una colección de entregables más o menos bien construidos o unos procesos de gestión más o menos rigurosos. El proyecto sirve si resuelve esos problemas.
Según vimos desde el inicio, la causa de la mayor parte de los fracasos en los proyectos TIC no se debe a causas tecnológicas, sino a problemas relacionados con la gestión del alcance (y, por tanto, de la comprensión de las necesidades de los clientes), problemas de comunicación y gestión de las expectativas de los usuarios y problemas relacionados con lo que el cliente tiene que hacer en su organización (liderar y comprometerse, asignar recursos, cambiar los procesos o la organización) y frecuentemente no hace.
Porque un proyecto es un esfuerzo de personas y es el manejo de las personas lo que lo conduce o no, al final del día, al fracaso o al éxito. Así es dentro del equipo de trabajo y en la relación con el cliente, los usuarios y los contratistas.
De manera que nos ha parecido adecuado dedicar un último capítulo a lo que uno de los autores clásicos de esta disciplina (Pinto y Millet, 1999) llamó "el lado humano" de la gestión de proyectos, y recopilar y desarrollar aquí algunos de los temas que hemos tratado más ligeramente a lo largo del resto de los módulos (como son los procesos de organización del trabajo, comunicación y gestión de expectativas) e introducir otros nuevos, presentando el conjunto de una forma un poco más sistemática de como se acostumbra a hacer en los manuales.
Creemos que una aproximación a la gestión de personas dentro de la gestión de proyectos no debe ser un enunciado de buenos propósitos, sino una disciplina en sí misma en la que deben alinearse, para tener éxito, varias clases de elementos:
1) El diseño de la organización del proyecto, es decir, la clarificación de los roles y responsabilidades de sus miembros, en particular, en los niveles de dirección, por parte del cliente y del equipo.
2) La gestión de los interesados (stakeholders), es decir, la identificación inteligente del impacto e influencia del proyecto sobre las diferentes partes de la organización, su predisposición a la adopción y las estrategias a desplegar.
3) Los procesos de comunicación, formal e informal, con relación a las partes interesadas y dentro del equipo, es decir, la gestión de los mensajes, medios, formatos, estilos, portavoces, periodicidad, etc.
4) La gestión y desarrollo de las personas individuales que forman el equipo y del equipo en su conjunto y, por lo tanto, las políticas y procesos de reclutamiento, asignación, desarrollo, formación y recompensa.
5) Las habilidades interpersonales que deben desarrollar los miembros del equipo y, sobre todo, el director o jefe de proyecto, en particular las de comunicación, toma de decisiones, liderazgo, motivación, trabajo en equipo, negociación y resolución de conflictos.
Finalmente, llamamos gestión del cambio (y no, ya lo dijimos, la gestión de los cambios en el alcance o en otras dimensiones del proyecto) a todas aquellas cosas que deben producirse en el cliente para que el proyecto tenga éxito. Esto incluye, asimismo, una comprensión clara de la misión del trabajo desde un punto de vista del negocio, el liderazgo y compromiso de la dirección (mostrado en las decisiones difíciles y la asignación de recursos) y acciones sobre la organización (roles y responsabilidades), los procesos de gestión y, muchas veces, los recursos humanos (en cantidad y calidad). E incluye un proceso activo y sistemático de manejar el cambio para que las cosas que tienen que pasar, pasen.
Gestión del cambio
La gestión del cambio merecería un capítulo separado (y como señalamos en su momento, un área de conocimiento diferenciada dentro de PMBOK y otros estándares de la profesión), ya que incluye una aproximación, procesos y tecnologías muy variadas y complejas en un ámbito disciplinario muy nuevo y poco codificado. Por nuestra parte incluimos en este capítulo algunos temas que refuerzan la gestión del cambio dentro del proyecto, pero sin darle de momento un tratamiento diferenciado y desarrollarlo a fondo.

Objetivos

Al término del estudio de este módulo, los estudiantes deberéis conocer y estar en condiciones de aplicar vuestros conocimientos en las siguientes materias:

  1. En qué consiste el "lado humano" de la gestión de proyectos y cuáles son sus diferentes componentes y las relaciones entre ellos.

  2. Comprender el diseño de la estructura de organización de un proyecto, los diferentes roles y responsabilidades, en particular el rol de jefe o director de proyecto y algunas de las herramientas más utilizadas.

  3. Comprender de una forma integral e integrada los componentes de la gestión de interesados, tanto en el diagnóstico como en la intervención para el éxito del proyecto.

  4. Comprender los componentes básicos de la comunicación dentro del proyecto y sus principales procesos de gestión.

  5. Comprender los principales componentes y procesos de gestión y desarrollo de las personas dentro del equipo y de construcción y desarrollo del equipo en su conjunto.

  6. Comprender las necesidades de desarrollo de las habilidades interpersonales imprescindibles para la gestión de las personas y sus relaciones dentro del proyecto.

1.El "lado humano" de la gestión de proyectos

"Estamos convencidos (y esta visión está soportada por evidencias sustanciales) de que la mayor parte de los fracasos en la implantación de sistemas de información se debe a fracasos en la gestión de los proyectos. Es decir, la mayoría de las razones por las cuales estos sistemas no se implantan con éxito no tiene que ver con causas puramente técnicas, sino con una gestión eficiente del proyecto. La gestión del proyecto quiere decir comprender el alcance y el calendario, establecer objetivos, descomponer el trabajo, gestionar los recursos, manejar el lado humano de la implantación y entender cómo superar las barreras de aceptación y uso de los sistemas por parte de su público objetivo" (Pinto y Millet,1999).
Desde que Pinto y Millet, autores del manual de referencia en la materia, escribieron esta afirmación, pocas cosas han cambiado, al menos de acuerdo con las evidencias científicas, los análisis que elabora la consultora The Standish Group sobre implantación de proyectos TIC en todo el mundo y la práctica profesional de clientes y empresas de servicios. Sus afirmaciones, pensadas para proyectos de implantación de sistemas de información, son aplicables a proyectos multimedia, donde los usuarios son internos y externos a la organización (los problemas de adopción y uso de la tecnología, aún más si incluyen transaccionalidad y compra, pueden ser aún más dramáticos) y, con matices, a muchos proyectos de telecomunicaciones, que no sean puramente de despliegue de infraestructura.
Como hemos venido presentando, los problemas relacionados con la implantación que tienen que ver con las personas no se producen sólo en el momento de la adopción de la tecnología, sino a lo largo de todo el proyecto, en la comprensión compartida de los objetivos de negocio, en la definición de las necesidades del proyecto, de los entregables, de los requisitos funcionales, de las exigencias de participación de los usuarios, de la toma de decisiones de la dirección, de la gestión de los cambios, de la integración con los sistemas heredados, de la realización de pruebas y de la transformación de la organización y procesos del cliente, por citar sólo algunos de los más críticos.
Rodríguez, García y Lamarca citan muchas razones de fracaso de los proyectos que tienen que ver con las personas (tabla 1).
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 1
Razones de fracaso de un proyecto relacionadas con las personas

  • Los miembros del equipo no tienen la formación adecuada.

  • Falta de supervisión.

  • Falta de personal.

  • Conflictos internos dentro del equipo.

  • Conflictos por asignación a más de un proyecto.

  • Miembros desmotivados.

  • Los miembros del equipo no aprenden.

  • Sobrecarga de trabajo, largos horarios.

  • Equipo desplazado todo el tiempo, de lo cual se resiente su vida familiar.

  • Falta de involucración de los equipos del cliente.

  • No aceptación del proyecto por personas clave del cliente.

  • Bajo rendimiento de personas clave del equipo.

  • Diferente visión de los objetivos entre los miembros.

  • El cliente no asigna recursos o no están cualificados.

  • Problemas con los subcontratistas
Para estructurar este capítulo, consideraremos los componentes del "lado humano" de la gestión de proyectos en cinco grupos (figura 1).
Figura 1. Componentes del ''lado humano'' de la gestión de proyectos
1) El diseño de la organización del proyecto, es decir, la clarificación de los roles y responsabilidades de sus miembros, en particular en los niveles de dirección, por parte del cliente y del equipo.
2) La gestión de los interesados (stakeholders), es decir, la identificación inteligente del impacto e influencia del proyecto sobre las diferentes partes de la organización, su predisposición a la adopción y las estrategias a desplegar.
3) Los procesos de comunicación, formal e informal, con relación a las partes interesadas y dentro del equipo, es decir, la gestión de los mensajes, medios, formatos, estilos, portavoces, periodicidad, etc.
4) La gestión y desarrollo de las personas individuales que forman el equipo y del equipo en su conjunto y, por lo tanto, las políticas y procesos de reclutamiento, asignación, desarrollo, formación y recompensa.
5) Las habilidades interpersonales que deben desarrollar los miembros del equipo y, sobre todo, el director o jefe de proyecto, en particular las de comunicación, toma de decisiones, liderazgo, motivación, trabajo en equipo, negociación y resolución de conflictos.
Todos estos componentes deben estar alineados entre sí (es decir, asegurar la coherencia entre unos y otros) y con el conjunto del proyecto.
Es importante señalar que cuando hablamos del "lado humano" no nos estamos refiriendo a componentes más o menos emocionales o psicológicos o, al menos, no sólo a ellos. Como veremos a continuación, el lado humano incluye dos clases de elementos:

  • Aspectos de estructura, organización, y procesos (sistemas), que pueden afectar al organigrama (del proyecto y de la empresa), a los roles y responsabilidades, las retribuciones o la promoción de las personas, dentro del proyecto, de la empresa proveedora de los servicios o del cliente.

  • Aspectos de procesos de gestión del proyecto formales (como la distribución de la información y la identificación y gestión de interesados), habilidades interpersonales que pueden adquirirse y desarrollarse (las habilidades de comunicación, motivación, o toma de decisiones) y aspectos que afectan a la "cultura" del proyecto o del cliente, y sobre los que cada vez existe una mejor información e investigación.

Rodríguez, García y Lamarca (2007) llaman al primer grupo componentes hard y al segundo grupo componentes soft, pero en ningún caso estamos hablando de psicología ni de magia, sino de procesos, técnicas y habilidades que pueden adquirirse con el estudio y, sobre todo, la práctica profesional.
Estos autores ponen un ejemplo en que puede visualizarse el conjunto.
Componentes hard y soft en el "lado humano" del proyecto
Si creamos un canal de atención al público por Internet, se puede modificar nuestra carga de trabajo de atención presencial o telefónica (disminuir o, curiosamente, aumentar) y la estructura de personal, generar o contratar externamente un servicio nuevo e integrarlo o no con nuestro servicio de administración (back-office), y pediremos a unos y otros habilidades diferentes. El proceso global de atención al público variará y quizá estructuremos una organización separada para dar esta gestión externa (front-office), con puestos de supervisión. Puede haber horarios y turnos distintos y una estructura salarial diferente. Estos serían los componentes hard.
Es probable que los departamentos tradicionales, con razón o sin ésta, vean en la nueva estructura un peligro para sus intereses. No es claro que no represente una mayor carga de trabajo sin recibir mayores recursos. Además, pueden sentirse postergados o peor retribuidos que la nueva organización. En todo caso, deberán ser formados en los nuevos procesos y en el manejo de los sistemas que se implantan. Dentro de la organización será importante identificar responsables de los nuevos procesos y conseguir el apoyo de mandos intermedios y de líderes de opinión entre el personal. También se deberá explicar el nuevo proceso y estructura a los representantes del personal y conseguir su no oposición. Desde el principio hasta el final, se deberá explicar bien qué se está haciendo para calmar resistencias y ganar apoyos o, al menos, neutralidad. Estos serían algunos de los componentes soft.
Fuente: Rodríguez, García, Lamarca (2007)
Finalmente, y para complicar las cosas (pero es que las cosas en los proyectos son complicadas), el "lado humano" se produce, al menos, en tres organizaciones diferentes:
1) El proyecto, como organización ad hoc, un equipo único reunido durante un tiempo para entregar unos productos o servicios.
2) El cliente, la organización destinataria del producto o servicio, con sus activos de estructura, procesos, cultura, sistemas de gestión y reglas de negocio, que encarga un proyecto que "cambiará" cosas. (Este es el ámbito de lo que modernamente se llama "gestión del cambio", que no trataremos en profundidad en este módulo.)
3) La organización u organizaciones proveedoras de los servicios (o productos), donde la mayoría de los miembros del equipo están sujetos a formas de organización, jerarquías, carreras profesionales, sistemas de evaluación y asignación a nuevos proyectos.

1.1.El "lado humano" en PMBOK

El estándar de la profesión ha ido reconociendo paulatinamente con mayor interés e intensidad los aspectos humanos de la gestión de los proyectos, y el propio PMI patrocina y publica cada vez más material sobre este tema.
Aunque, como hemos comentado, su visión continúa siendo limitada y poco estructurada y sistemática, en nuestra opinión.
En PMBOK (2008), los aspectos de organización del proyecto y gestión del equipo están incluidos en el área de conocimiento de gestión de recursos humanos. La organización del proyecto (los roles y responsabilidades atribuidos a cada miembro) es el contenido central del proceso de desarrollo del plan de recursos humanos en la etapa de planificación. Los aspectos de gestión de las personas y gestión del equipo se desarrollan durante la etapa de ejecución.
En PMBOK (2008), los procesos de comunicación y gestión de interesados se incluyen en el área de conocimiento de gestión de la comunicación. La gestión de interesados se realiza en la etapa de iniciación (con la identificación y registro de interesados) y la en la etapa de ejecución (cuando se hace la gestión activa de los interesados). La comunicación se lleva a cabo en la etapa de planificación (cuando se prepara el plan de comunicación del proyecto), durante la ejecución (principalmente, mediante la distribución de la información) y el control (la preparación de los informes de progreso).
La última edición de PMBOK (2008) incluye un anexo sobre habilidades interpersonales que debe desarrollar el jefe de proyecto.
En PMBOK, ni en la última edición ni en las anteriores, existe una visión comprensiva de la gestión del cambio, probablemente porque se parte de la interpretación de que son materias o decisiones que debe tomar el cliente y que son ajenas al proyecto. También probablemente porque PMBOK es una aproximación generalista para toda clase de proyectos, no un sectorial de TIC y en otros sectores de actividad las necesidades de involucración del cliente para el éxito del proyecto y los problemas relacionados con el uso y adopción de la tecnología por el cliente no son tan severos.
En todo caso, a lo largo de los siguientes apartados, haremos uso de la referencia de PMBOK (2008) cuando la aproximación sea más útil o, en todo caso, remitiremos al alumno a su lectura o estudio para no perder la consistencia con el resto de los materiales de este material.

2.La organización del proyecto

Entendemos aquí por organización la definición de roles y responsabilidades de los miembros del proyecto (cualquiera que sea su procedencia: cliente, empresa proveedora, contratistas) con relación al proyecto y la estructura de toma de decisiones y distribución del trabajo.
Las estructuras de organización incluyen los órganos individuales (personas que asumen roles y tienen responsabilidades) y también los órganos colegiados (comités y comisiones que tienen atribuidas funciones dentro del proyecto).
Como hemos venido diciendo, en proyectos TIC grandes y complejos, las diferencias entre lo que está dentro del proyecto y lo que está fuera, lo que es negocio y lo que es proyecto, lo que es parte del equipo y lo que son partes interesadas se difuminan y la gestión del jefe o director de proyecto es, en buena medida, comprender y manejar ese conjunto de interacciones. Profundizaremos en este punto cuando tratemos la gestión de interesados.

2.1.Roles que afectan directamente al proyecto

Sin embargo, sí que hay, al menos, tres roles demasiado cercanos al proyecto como para dejarlos ahora de lado: la alta dirección, los directores funcionales y la oficina de proyecto.
1) La alta dirección que, según vimos, selecciona y aprueba los proyectos en función de unos objetivos y beneficios de negocio, los dota de recursos y asigna al jefe de proyecto.
2) Los directores funcionales y de negocio (entre ellos, el director de informática) que deben apoyar los objetivos del proyecto en su área, asignar los recursos y prestar todo el apoyo necesario para el éxito.
3) La oficina de proyecto (project management office), cada vez más frecuente en proyectos grandes, que puede tener un rango muy amplio de funciones, desde el seguimiento y control del cumplimiento de los entregables, presupuestos y calendario, hasta la gestión de interesados, y que puede tener responsabilidad ejecutiva o meramente de apoyo.
Clarificar el rol de la oficina de proyecto es clave
Implementar una oficina de proyecto requiere entender muy bien qué se espera de ella, comprender los requisitos del proyecto o proyectos y gestionar las expectativas (o sea, ¡es casi en sí mismo un proyecto!).
Después de decenios de implantación de oficinas de proyectos TIC, en Estados Unidos, aproximadamente sólo la mitad de los directores de organización y sistemas (CIO) se muestran satisfechos con su rendimiento en una encuesta publicada en CIO Magazine. Los que se muestran satisfechos lo hacen porque piensan que la oficina de proyecto ha ayudado a implantar estándares de gestión de proyecto, mejorar la satisfacción de los clientes internos y alinear los proyectos con la estrategia de negocio.
Fuente: Snyder y Parth (2007)
Otro aspecto a tener en cuenta, y que aquí durante todo el tiempo simplificaremos, es que cada vez es más habitual encontrar organizaciones de proyecto donde se produce una cierta relación especular (de espejo) entre la estructura del cliente y la estructura del proveedor o proveedores. Es decir, si el proveedor tiene un jefe de proyecto, el cliente tiene un jefe de proyecto. Si el proveedor tiene un responsable funcional y otro técnico, el cliente tiene un responsable funcional y otro técnico. Si el proveedor tiene un responsable para la integración, el cliente tiene un responsable para la integración. Esto suele tener grandes ventajas desde el punto de vista de la comunicación y relación con el cliente, pero a veces hace la organización del trabajo muy compleja y la autoridad se diluye.

2.2.Roles principales en el proyecto

Dentro del proyecto, hay tres roles clave: el patrocinador, el gerente o jefe de proyecto y los miembros del equipo.
1) El patrocinador, o sponsor, normalmente tiene un papel de dirección estratégica y relación dentro del proyecto y con relación a terceros. Es el promotor de la definición del proyecto, conoce bien los objetivos y las prioridades y el impacto en el negocio. Asegura que el equipo tiene la dotación adecuada en cantidad y calidad y se ocupa de motivarlo. Por ejemplo, en la implantación de un ERP de gestión integral de recursos humanos, el sponsor sería normalmente el director de recursos humanos de la empresa.
2) El gerente o jefe de proyecto tiene la responsabilidad de supervisar y controlar la ejecución del proyecto para asegurar su cumplimiento en objetivos, tiempo y coste. Asume también las relaciones ordinarias con el equipo de la empresa contratada, en su caso, que suele tener a su vez un director de proyecto, responsable de todos los recursos puestos a disposición por el contratista y los subconstratistas. Por su importancia dentro de esta materia, dedicaremos a esta figura un apartado a continuación.
3) Los miembros del equipo tienen una responsabilidad principalmente técnica, de ejecución de la parte del trabajo que tienen asignada con su aportación profesional y en colaboración con otros miembros del equipo y personal del cliente. Suelen tratar las operaciones con un supervisor o líder intermedio del proyecto, y éstos, con el gerente. Actualmente, los miembros del equipo suelen pertenecer a la organización del cliente, a su departamento de informática y a empresas externas.
Cada figura juega un papel diferente en cada fase del proyecto. En general, corresponde a la alta dirección la aprobación del proyecto, por sí misma o conjuntamente con el Comité de Dirección o las direcciones funcionales afectadas. El patrocinador del proyecto es un director funcional (o el director de informática) y normalmente realiza las propuestas para la aprobación y es el que decide en la fase de definición del proyecto. El responsable operativo del proyecto, una vez aprobado y definido, es el gerente o jefe de proyecto, quien debe decidir (en el entorno establecido de contenido, coste y tiempo) en las fases siguientes hasta el cierre.
Cuando se producen desviaciones sobre la definición del proyecto, su aprobación depende del patrocinador del proyecto, las direcciones funcionales o la dirección general, según el tipo de problema. Normalmente, el jefe de proyecto y los miembros del equipo trabajan y toman decisiones en el nivel de las actividades. El resto de la estructura hacia arriba, toma decisiones en el nivel de hitos y entregables (EDT).

2.3.El director o jefe de proyecto

El jefe de proyecto es el responsable del proyecto en el día a día. Tiene que organizar el trabajo dentro del equipo de proyecto y en sus relaciones con la organización cliente. Es la persona que dirige el proyecto desde la planificación hasta el cierre (a veces interviene también en las fases anteriores), y tiene la responsabilidad del cumplimiento de objetivos en tiempo y costes y de los recursos asignados para ello. Para cumplir con éxito su función, debe estar investido de la autoridad equivalente a su responsabilidad.
El papel del jefe de proyecto es gestionar. Gestionar un proyecto TIC consiste en lo siguiente:

  • Hacer que las cosas se hagan en colaboración con otros.

  • Marcar un camino y hacer que la gente se mueva en esta dirección con éxito.

  • Mejorar el rendimiento individual y del grupo mediante el consejo y la evaluación.

  • Relacionar al equipo con la organización, con otros equipos y con el cliente, y facilitarle información y recursos.

  • Tener y compartir una visión amplia del proyecto dentro de la empresa, y entender los beneficios del proyecto para el cliente y lo que la tecnología aporta al negocio.

Gestionar requiere, por lo tanto, un conjunto de habilidades interpersonales, a las que nos referimos en un apartado posterior de este módulo. Un buen líder muestra una visión y una dirección clara, genera confianza y crea sentimiento de pertenencia y deseo de estar en el equipo, ayuda en el desarrollo personal mediante el coaching, tiene a veces algunas cualidades especiales o carisma y además tiene competencias técnicas que el equipo reconoce.
En todo caso, como dicen Andersen y otros (2003), es de poco valor o un poco frustrante ir comparando a la gente que hace proyectos y listas de super-cualidades. Es más importante entender cuáles son los requisitos esenciales del puesto, con independencia de las cualidades personales y directivas. Un buen jefe de proyecto:

  • Puede hacer una valoración realista del estado del proyecto, tanto con relación al cumplimiento de los hitos y el progreso del trabajo, como con relación a la situación de las personas del equipo.

  • Puede proponer y ejecutar acciones y decisiones para corregir la situación si hace falta, de forma flexible y efectiva, para el éxito del trabajo y de la gente.

  • Puede comunicar lo anterior de forma adecuada en el contenido, en la forma y en el tiempo, para obtener la comprensión y el apoyo de todas las partes involucradas.

Este balance de madurez, flexibilidad y realismo entre las necesidades del proyecto y las de las personas es lo más importante en el jefe de proyecto. Un buen jefe de proyecto no es un tecnócrata (el mejor conocedor e implantador de la solución tecnológica), un burócrata (el mejor controlador y metodólogo de la gestión de proyectos) ni un vendedor (el mejor comunicador de los éxitos, reales o imaginarios, del proyecto). Pero sí que es un buen gestor de personas, un buen coach, un buen comunicador y una persona orientada a la acción.
Quién deber ser jefe de proyecto
Normalmente, un jefe de proyecto ha sido antes miembro de un equipo, por lo general un miembro exitoso, y ha aportado su conocimiento funcional o técnico al equipo. Aunque el jefe de proyecto también tiene una aportación técnica, no está ahí principalmente para esto y no es verdad que el gerente sea "el que más sabe". En los proyectos TIC, es habitual que el jefe de proyecto tenga una formación o experiencia técnica. Esto facilita la relación con el equipo y el conocimiento de las metodologías, técnicas y herramientas que se utilizan en el trabajo.
Pero no tiene que ser necesariamente así. En otras ocasiones, el sponsor prefiere escoger una persona de su organización o departamento, que conoce bien el negocio y los procesos de trabajo. Para complicar el dibujo, las empresas externas que colaboran en la realización del trabajo y los subcontratistas de la empresa adjudicataria también colocan y deben colocar un jefe de proyecto en su área de responsabilidad. De nuevo, utilizando la matriz de roles y responsabilidades, es bueno clarificar y documentar el rol de cada uno. Aunque puede variar en cada situación, nos inclinamos por el siguiente modelo:

  • Un director o jefe de proyecto de la organización que realiza el encargo, con formación y experiencia gestionando proyectos, y que sea informático o con conocimiento y capacidad de diálogo en ese ámbito. Le corresponde la supervisión global del trabajo y tomar las decisiones que se han descrito, por sí mismo o conjuntamente, con alguna de las siguientes figuras.

  • Un líder funcional, extraído del área de negocio, que representa los intereses (objetivos) del patrocinador con relación al proyecto, conoce el negocio y los procesos. Asigna, controla y motiva a los miembros del equipo que proceden del cliente.

  • Un jefe de proyecto de la organización contratista, responsable del cumplimiento de los objetivos descritos en el contrato. Controla y motiva a los miembros del equipo que le han sigo asignados y a las empresas subcontratistas, en su caso.

Este 'triunvirato' asume actualmente, en las organizaciones y proyectos complejos, la 'dirección' del proyecto.
Fuente: Rodríguez, García, Lamarca (2007)

2.4.El Comité de Dirección

El jefe de proyecto reporta normalmente a un comité de dirección, donde están representadas las diferentes partes interesadas en el éxito del proyecto, que aportan recursos y que tienen que tomar decisiones. Normalmente está presidido por el sponsor o patrocinador.
Corresponde al comité:

  • Aprobar el plan de hitos y descomposición del trabajo (EDT).

  • Aprobar el reparto de roles y responsabilidades en el proyecto.

  • Asegurar la asignación de recursos.

  • Asegurar la comunicación dentro de la organización y entre sus partes.

  • Conocer y aprobar el progreso del proyecto, de acuerdo con el plan.

  • Proponer o tomar decisiones sobre las desviaciones de alcance, presupuesto y tiempos.

En principio, no es bueno que el comité de dirección sea decisorio y no son buenas las decisiones tomadas en comités. La organización de un proyecto debería ser fundamentalmente jerárquica y las decisiones deberían tomarse en los órganos individuales del proyecto o, si le sobrepasan, en las órganos directivos de la compañía. Sin embargo, en organizaciones y proyectos complejos es casi inevitable un nivel de coordinación y transacción entre unidades o negocios independientes, con objetivos distintos y que aportan diferentes recursos. Deben aceptarse los costes de transacción de estas situaciones, las reglas del juego (en especial, el procedimiento y el tiempo para tomar decisiones), establecer una cultura de trabajo en equipo (diferente de las responsabilidades de línea, propias de la organización convencional) y desarrollar, por parte del sponsor y del jefe de proyecto, las habilidades de comunicación y negociación que esto requiere.

2.5.La matriz de roles y responsabilidades

Cada proyecto es diferente, ocurre en una organización distinta, con reglas únicas, atiende problemas de negocio específicos y tiene componentes técnicos y personales diversos. Es importante dedicar tiempo a entender todo esto y a diseñar la mejor manera de resolver los problemas e integrar a todos los componentes y establecer un diálogo constructivo con el cliente y luego dentro de los equipos de trabajo sobre todos los aspectos organizativos. Muchos proyectos fallan (no cumplen sus objetivos), o son ineficientes (se utilizan mal los recursos) o resultan frustrantes para los equipos porque no se clarifica la mejor contribución de cada miembro, la relación entre ellos, las relaciones con el cliente y no se toman las decisiones adecuadas, a tiempo y por quien debe hacerlo.
El plan de gestión de recursos humanos, elaborado en la etapa de planificación, debe proporcionar una definición clara de los recursos humanos asignados al proyecto, en cantidad y calidad, el papel de cada uno sobre los productos y actividades, las necesidades de supervisión y control y el momento de entrada y salida del proyecto.
Con relación al papel de las personas dentro del proyecto, deben clarificarse varios conceptos diferentes, que en ocasiones se confunden (PMBOK (2008, págs. 222-223):

  • Rol: describe la parte del proyecto de la que una persona es responsable. El rol debe clarificar el nivel de autoridad, responsabilidad y las fronteras con otros roles. (De nuevo, el inglés es más rico y preciso que el español y el catalán en estos temas. El rol representa lo que en inglés se llama accountability, que quiere decir, "dar cuentas de", o sea, a quién hay que premiar si algo único y distinguible sale bien, o reprochar si algo no sale bien.)

  • Autoridad: la autoridad tiene que ver con los derechos formalmente asignados a alguien de aplicar recursos, tomar decisiones y firmar o rechazar aprobaciones. Lo mejor ocurre cuando responsabilidad y autoridad van juntas. Responsabilidad sin autoridad suele ser una mala combinación.

  • Responsabilidad: responsabilidad es el espacio, el ámbito de trabajo que cada uno tiene que desarrollar dentro del rol que tiene asignado para completar las actividades o productos que le tocan en el proyecto. (Todos los miembros del equipo tienen un ámbito de responsabilidad, pero pueden no ser "accountable", no son los que tienen que dar cuentas, porque lo hará un superior, normalmente.)

  • Competencia: es la habilidad o capacidad que tiene alguien para hacer algo. Nadie debería ser asignado para hacer algo que no sabe o no puede hacer y, si inevitablemente tiene que ser así, debe ser por poco tiempo y con la ayuda, formación y supervisión adecuada. El plan y la gestión de recursos (en particular, el proceso de asignación de equipo) debe asegurar que el proyecto se dota de las personas con las competencias adecuadas.

La matriz de roles y responsabilidades es el mejor instrumento para mostrar la asignación de roles dentro del proyecto y en las diferentes fases, especialmente en proyectos complejos en los que participan múltiples departamentos, personal interno y externo, contratistas y subcontratistas.
En el eje vertical se mostrarán las diferentes materias a resolver (normalmente, los hitos o actividades del proyecto). En el eje horizontal, los diferentes miembros que participan. Normalmente, en el nivel de hitos o EDT se recoge el personal directivo del cliente, diferentes departamentos y proveedores y los roles directivos dentro de la empresa contratada, si es el caso. En cada casilla, se representan los roles.
En su forma más sencilla, la matriz RACI, los roles son sólo cuatro:
1) Responsible (ejecuta): el encargado de realizar o ejecutar el trabajo.
2) Accountable (responsable): el responsable último, el supervisor, el que tiene la autoridad, toma decisiones o tiene que dar cuentas sobre el trabajo realizado.
3) Consult (es consultado): alguien que debe ser consultado y apoyar el trabajo.
4) Inform (es informado): alguien que debe ser informado.
En la tabla siguiente (tabla 2) mostramos un ejemplo de matriz RACI para un trabajo típico de desarrollo de un sistema de información.
Tabla 2. Ejemplo de matriz RACI
En la práctica, en los proyectos actuales, la cantidad y sofisticación de roles ha aumentado. En la aproximación GDPM (gestión de proyectos orientada a objetivos), de Andersen y otros (2003), se establece un número más complejo de roles que se muestra en la tabla siguiente (tabla 3).
Andersen y otros, 2003
Tabla 3. Roles que pueden darse en un proyecto

  • X Ejecuta el trabajo

  • D Toma decisiones, en solitario o en último lugar

  • d Toma decisiones conjuntamente o parcialmente

  • P Gestiona el trabajo y controla el progreso

  • S Proporciona soporte o apoyo

  • C Debe ser consultado

  • I Debe estar informado

  • A Está disponible para dar opinión o consejo si se requiere
Un resultado práctico en un nivel de detalle inferior se muestra en la tabla 4 para el ejemplo de planificación de un portal de atención al ciudadano que vimos en el módulo "Planificación del proyecto".
Tabla 4. Ejemplo de tabla de descomposición de actividades con asignación de roles
La matriz de roles y responsabilidades, cualquiera que sea el formato elegido (PMBOK, 2008), proporciona otros formatos además de los mostrados aquí, y debe considerarse uno de los documentos básicos de la carpeta de proyecto, al mismo nivel que el plan de proyecto, el acta de constitución o los documentos de aceptación de los productos.

3.Gestión de interesados

Los interesados en un proyecto (o stakeholders, en inglés) son todas las personas y organizaciones que se verán afectadas por el desarrollo del proyecto, sea directamente, porque participan en el proyecto de alguna manera, o indirectamente, porque el funcionamiento del producto o servicio que resultará del proyecto les afectará de una forma u otra. (La gestión de interesados es una parte importante de la "gestión del cambio".)
A lo largo del proyecto, la gestión de interesados aspira a identificarlos correctamente, entender sus expectativas e interés en el proyecto, calificar su influencia dentro de la organización y establecer estrategias para su manejo para facilitar la participación de aquellas personas que son necesarias para el éxito y, en general, la aceptación del proyecto y los productos o minimizar las barreras de adopción en el seno del cliente. Esto no es sencillo, porque entre las partes existen frecuentemente intereses en conflicto, latentes o explícitos, que el proyecto hace más evidentes.
El proceso de gestión de interesados, según hemos comentado, está incluido en PMBOK (2008), en el área de conocimiento de comunicación y se desarrolla en la etapa de iniciación y en la de ejecución.
La gestión de las expectativas de los interesados, según PMBOK
Gestionar las expectativas de los interesados incluye actividades dirigidas hacia las partes interesadas en el proyecto para influir en sus expectativas, atender a sus preocupaciones y resolver incidencias (issues), tales como:

  • Manejar activamente las expectativas de los interesados para aumentar la probabilidad de aceptación del proyecto, negociando e influyendo sobre sus deseos para conseguir y mantener los objetivos del proyecto.

  • Atender a sus preocupaciones (concerns), que todavía no se han convertido en incidencias (issues), para anticipar problemas futuros. Estas preocupaciones necesitan ser puestas encima de la mesa y discutidas y examinados los riesgos.

  • Clarificar y resolver las incidencias (issues) que han sido identificadas. La resolución puede resultar en una petición de cambios o puede ser atendida fuera del proyecto, en otra fase o en otra instancia de la organización.

Fuente: PMBOK, 4.ª ed. (2008, pág. 261)
Genéricamente, se pueden considerar interesados los siguientes grupos:

  • Los usuarios son las personas internas o externas a la organización que deberán usar los sistemas o tecnologías que se están implantando. Existen muchos niveles, capas o tipos de usuarios, y es muy importante entender el proceso de adopción (aceptación y uso efectivo) de la tecnología en cada caso.

  • Los directores funcionales o de negocio afectados por el proyecto, sea como usuarios, por su relación o influencia en el proceso de negocio, por su aportación de recursos o porque el proyecto modifica su estatus o responsabilidad. Uno o varios directores funcionales, según vimos, pueden ser el sponsor o patrocinador del proyecto, en cuyo caso, son más una parte del proyecto que un interesado (y es importante que lo entiendan así y jueguen ese rol activamente).

  • Los departamentos de TIC u otros relacionados con la organización y los sistemas de información, que pueden variar en cada organización. Con frecuencia, se encontrarán en un rol doble, como interesados o afectados por el proyecto (que afectará a sus responsabilidades, carga de trabajo, capacidades y cuota de poder, casi siempre) y, al mismo tiempo, serán parte del proyecto y deberán aportar conocimiento y recursos. Suelen ser interesados especialmente complicados de manejar.

  • Los proveedores de productos y servicios TIC, en primer lugar los relacionados con el proyecto, pero eventualmente otros dentro del cliente, como los que proporcionan los servicios de soporte de usuarios, gestión de las redes, mantenimiento de aplicaciones y todos los que gestionan las aplicaciones heredadas (legagy, en inglés) a las que los productos del proyecto sustituyen o con las que se integran. Para muchos, el proyecto es una amenaza.

  • Los jefes de proyecto fronterizos o relacionados con el nuestro, así como las oficinas de programa (en aquellas organizaciones acostumbradas a gestionar un programa o portafolio de proyectos de una manera integrada) y, en su caso, la oficina de proyecto.

  • Si el proyecto incluye una carga mayor de aspectos de gestión del cambio, estarán involucrados muchos otros miembros del equipo de dirección, como la dirección de recursos humanos, responsables de oficinas locales o regionales y probablemente la alta dirección.

3.1.Los aspectos políticos de cualquier proyecto

En primer lugar, el estudiante y profesional de las TIC, y más aún si le toca jugar el rol de jefe de proyecto, necesita reconocer desapasionadamente el papel que la política tiene en las organizaciones, y que los proyectos (y sus productos resultantes) alteran inevitablemente los equilibrios de poder vigentes. Las TIC pueden ser un producto neutro, no lo discutiremos ahora y aquí, pero desde luego no lo es su uso. Sin reconocer (y seguidamente gestionar) los componentes políticos de cualquier proyecto TIC, es imposible entender la mayoría de las claves de éxito o fracaso del proyecto y por tanto, es bastante probable, que estemos poniendo las bases de un sonoro fracaso.
Lo segundo que necesita el estudiante, el practicante y el jefe de proyecto es reconocer que él también tiene intereses, emociones, preferencias, apegos y desapegos, que se ponen en juego durante la realización del proyecto. No es una estatua de hielo a salvo de sus intereses y emociones y todos éstos influyen en sus relaciones, en su interacción con las personas e, inevitablemente, en sus decisiones. Es bueno, por lo tanto, que aprenda a reconocerlos y a mostrarlos honradamente, si quiere hacer algo con ellas y ellos y que se conviertan en algo productivo para el trabajo, el equipo y el cliente. Las actitudes ingenuas (tanto como las actitudes deshonestas, del "tiburón" o pescador en río revuelto) no sirven para nada.
Pinto y Millet (1999) resumen en cinco proposiciones, sustentadas por la evidencia científica, una visión desapasionada, tranquila y natural de lo que pasa en cualquier organización cuando ocurre un proyecto y, con el proyecto, las decisiones de asignación de recursos, reparto de responsabilidades y cambios en los procesos y organización del negocio y en las formas de trabajar:
1) Las decisiones importantes en cualquier organización se refieren a la asignación de recursos escasos. La decisión de hacer o no un proyecto TIC y qué proyecto se hace compite con otras demandas de la organización. Alguien gana y alguien pierde.
2) Durante el proceso de asignación de recursos y toma de decisiones, se producen negociaciones, que tienen componentes racionales y otros emocionales. Nadie gana todo o pierde todo. Se establecen compromisos y victorias y derrotas parciales, entre gente que está condenada a entenderse, trabajar junta y establecer alianzas.
3) Ninguna organización es monolítica. Cada organización está compuesta por grupos y coaliciones de intereses, incluso cuando existe una cultura y autoridad corporativa fuerte y compartida. Incluso cuando se produce una decisión corporativa, compartida, consensuada y negociada, es normal que aparezcan conflictos de interés o rechazo por parte de algunos grupos de la organización que pueden entender que su posición se debilita o se daña, real o potencialmente.
4) Estos grupos de interés difieren en objetivos, valores, actitudes, prioridades, agenda y en otras muchas cosas. Estos grupos pueden ser departamentales (finanzas frente a marketing), geográficos (Europa frente a América) o de origen o formación (en las fusiones, por ejemplo). Este proceso se llama "diferenciación organizativa". Por este motivo, los grupos con frecuencia pueden estar inclinados a satisfacer en mayor medida sus propios intereses que los de la dirección o los de la empresa como un todo.
5) Como corolario, debido a la escasez de recursos, las heridas y compromisos que produce la negociación y las diferencias e intereses privados de los grupos, la discusión sobre el poder o la aparición del conflicto no son efectos secundarios, indeseados o evitables, sino que son algo completamente racional, lógico y normal en cualquier organización.
Por nuestro lado, añadiríamos que la aparición de un proyecto TIC, en especial si es grande, complejo, si afecta al negocio y si atraviesa diferentes departamentos o negocios dentro de una corporación, introduce un desequilibrio en las estructuras más o menos estables de distribución del poder que hace aún más inevitable y central la aparición de conflictos. En efecto, la evidencia muestra, de nuevo citando a Pinto y Millet (1999), que contra lo que podríamos imaginar el comportamiento político es mucho más frecuente en algunos ámbitos como los proyectos de cambio estructural o las implantaciones de nuevos sistemas de información, que por ejemplo en el manejo de las quejas del personal.
Y no pasa nada. Lo que hay que hacer es reconocerlo, entender la influencia e impacto de cada parte sobre el proceso de adopción y gestionarlo adecuadamente.

3.2.Cómo se gestiona la política en el proyecto

Lo primero, insistamos, es reconocerla. Y establecer el proceso, las herramientas, la cultura y la sensibilidad para reconocerla y documentarla.
Herramientas como el mapa de interesados pueden ser útiles para empezar (figura 2).
Figura 2. Mapa de interesados
Lo segundo es ver que cada grupo requiere una estrategia diferente y que no son tantos.

  • No parece que debamos dedicar mucho tiempo a los neutros ni a aquellos cuya colaboración no necesitamos (si acaso, mantener las antenas abiertas por ver si pueden pasar al grupo de opositores o si de pronto les necesitamos), ni tampoco a aquellos cuyo impacto e influencia es bajo. El problema y la oportunidad la tenemos en aquellos cuyo impacto e influencia es alto (y acaso medio), cuya cooperación es necesaria y cuya posición es de entusiasmo o de oposición. Esos son nuestro objetivo y a los que debemos dedicar tiempo y esfuerzo.

  • Un entusiasta, cuya cooperación es necesaria y que tiene un impacto alto, puede ser un campeón (en inglés, champion) interno del proyecto, alguien que hará de propagandista, convencerá a los neutrales y debilitará a los opositores. Necesitamos champions.

  • Con relación a los neutrales y los opositores, es imprescindible reconocer que nadie tiene por qué compartir nuestro entusiasmo de entrada y que es lógico que vean las dificultades y barreras antes que los beneficios. Beneficios y barreras tienen que ser personalizados. El jefe de proyecto tiene que entender para cada interesado clave algo muy sencillo: "¿qué gano yo con esto?" (en inglés, le llaman la técnica WIIIFM, what is in it for me?). Si el proyecto es capaz de responder esta pregunta pronto, con ejemplos o visitas a otros clientes, con prototipos, mostrando el soporte y apoyo en la implantación y post-implantación, tendremos mucho ganado. También suele ser práctico dejar de invertir o mantener los sistemas heredados y mostrar las deficiencias de los sistemas actuales.

  • La gestión de los opositores recalcitrantes a veces requiere cierta dureza y es bueno que así sea. Su posición debe ser sistemática y objetivamente debilitada en las reuniones colectivas, debe buscarse su aislamiento o, si su participación es imprescindible y ésta no se está produciendo en la forma debida, incluso pedir su sustitución al sponsor del proyecto o a la alta dirección. El cliente y la misión del proyecto son lo primero y no podemos permitirnos nada que los ponga en riesgo.

Frecuentemente, los interesados, una parte de ellos o de su personal, son miembros de los equipos de proyecto o tienen alguna participación en determinadas fases. Si son tratados como parte del equipo, si comparten los objetivos y cooperan entre sí, si trabajan física e intelectualmente juntos resolviendo problemas, si comparten un ambiente cohesionado y motivado, es muy probable que su aceptación del proyecto, la comprensión de las dificultades y el esfuerzo extra de la transición aumenten y, con ello, el éxito del trabajo.
La adopción de la tecnología
Sí, la comunicación es importante, pero la comunicación importante es la que se refiere a lo que el proyecto dará y lo que no dará y en qué condiciones, y en compartir con el cliente al máximo nivel cuáles son, en último extremo, las condiciones de éxito del proyecto. En esto es en lo que más se suelen equivocar los profesionales de las TIC y las empresas de servicios y la mayor causa de frustración de los clientes, como ya hemos dicho.
El éxito del proyecto, en última instancia, no consiste en la aceptación de los entregables y el cobro de las facturas, sino en tres elementos que suelen escapar del proyecto, en el alcance y en el tiempo (Pinto y Millet, 1999):
1) Que el sistema lo use quien lo tiene que usar y para lo que lo tiene que usar (el caso más llamativo en el ámbito de las telecomunicaciones han sido las super-autopistas de la información, infrautilizadas durante más de una década, o el de la mayoría de las aplicaciones web transaccionales públicas y algunas privadas, pensadas desde la oferta y no desde la demanda). La comprensión y la gestión del proceso de adopción de la tecnología por los usuarios internos y externos es clave.
2) Una implementación exitosa de productos o servicios TIC requiere inevitablemente modificaciones, tanto en el producto como cambios en el cliente. Existe un proceso de adaptación mutua, que tiene que ver con la "gestión de los cambios" en el proyecto y con la "gestión del cambio" en el cliente.
3) Los beneficios reales de un proyecto de implantación de soluciones TIC se observan con el tiempo, cuando el cliente los ha incorporado plenamente a sus operaciones y ha realizado los cambios necesarios en sus procesos de trabajo. Es muy difícil evaluar el éxito de una implantación al acabar el proyecto y con la aceptación de los entregables.
La difusión de las innovaciones
El proceso de adopción de la tecnología por los usuarios internos y externos es muy desconocido y misterioso para los profesionales de las TIC y los jefes de proyecto, que acostumbran a despacharlo con la entrega de manuales de usuario y sesiones de formación. Pero se ha estudiado para otras tecnologías y profesiones (en especial, desde la aparición de la obra de Everett Rogers, Diffussion of Innovations en 1965) y, en los últimos años, también para las tecnologías de la información, tanto en entornos limitados (en el interior de las organizaciones) como en entornos masivos (por ejemplo, para usuarios de soluciones web abiertas al público).
Según la teoría de Rogers, cualquier innovación sufre un proceso de adopción social que atraviesa una serie de estadios, en los cuales diferentes proporciones del público objetivo asimilan y usan la innovación, hasta que la adopción es casi completa dentro del sistema social al que va dirigida. De acuerdo con este modelo es posible identificar cinco grupos de adoptantes (los innovadores, los adoptantes tempranos, la mayoría temprana, la mayoría tardía y los rezagados) que se distribuyen en una proporción de frecuencias que adopta una forma similar a una curva normal. La inclinación de la curva está determinada por la velocidad (el ratio de adopción) en que el proceso de adopción se produce (figura 4). Una masa crítica de usuarios (y por tanto, un proceso sin retorno) se consigue cuando se alcanza el 50% de la demanda.
Figura 3. El proceso de adopción de las innovaciones
Fuente: E. Rogers (2003). Diffussion of Innovations (5.ª ed., 1995, 2003)
Si analizamos el proceso individual de adopción, éste dependería principalmente de aspectos relacionados con el producto, el contexto situacional y la relación con otros compradores. Por ejemplo, en aplicaciones tecnológicas, la percepción de utilidad, la presión de otros usuarios o partes de la cadena, la adopción por líderes de opinión y un contexto de autoridad suele facilitar la adopción en un contexto organizativo. En cambio, en Internet, parece que la adopción de una aplicación está ligada a la percepción de utilidad, la frecuencia e intensidad de uso, la sensación de seguridad y la experiencia individual del usuario, por ejemplo, con relación a la usabilidad y tiempo de respuesta.
El proceso de adopción sigue un ciclo que pasa por los estadios de 1) conocimiento de la oferta, 2) desarrollo del interés y predisposición a la prueba, 3) decisión y ejecución de la prueba, y 4) compra repetida o leal.
A través de técnicas adecuadas, es posible analizar la situación de nuestros usuarios potenciales con relación al proceso de adopción y actuar sobre cada grupo mediante una diferente mezcla de técnicas, además de las de autoridad, que proceden fundamentalmente del mundo del marketing y la comunicación empresarial.

4.La comunicación

Desde el inicio de este material hemos venido diciendo que gestionar proyectos quiere decir dos cosas:
1) Asegurar que los proyectos se completan satisfactoriamente y que se consiguen sus productos y resultados últimos, en alcance, tiempo, costes y calidad (incluyendo la aceptación y uso por el cliente).
2) Hacerlo de manera que se pueda predecir y controlar su evolución y explicarlo satisfactoriamente al equipo de trabajo y al cliente.
Tan importante como hacer bien el proyecto, decíamos, es poder y saberlo explicar y asegurar su comprensión.
La comunicación es central en el proceso de gestión de proyectos y afecta a todos los procesos y áreas de conocimiento. Si gestionar un proyecto es gestionar la relación con las personas (el cliente, el equipo, la organización en la que servimos), la relación con las personas se basa en la comunicación.
La comunicación en el eje del proceso de consultoría
"Cuando me inicié en la profesión de consultor en 1989, lo hice en una firma de consultoría estratégica y de la mano de gente que provenía de Booz, Allen and Hamilton (hoy Booz and Co.) en el Reino Unido. La primera formación que recibí fue su aproximación o método (jamás le llamaron "metodología") de gestión del proceso de consultoría, en definitiva, de hacer proyectos.
Recuerdo que la representación gráfica del proceso era una rueda con varios radios (similar a la que se usa a veces para representar las "áreas de conocimiento" de PMBOK), en cuyo eje estaba la COMUNICACION. La comunicación se relacionaba con todos los demás procesos y etapas del trabajo y se planificaba al comienzo del proyecto, incluso antes, en las fases de aproximación comercial y preparación de propuestas.
Desde el comienzo del trabajo, por ejemplo, se trabajaba con la visión final de los informes y presentaciones al cliente, que se diseñaban y se iban completando desde muy pronto, de manera que en cualquier momento se estaba en condiciones de preparar con poco esfuerzo un producto intermedio.
La formación que recibíamos para hacer entrevistas, reuniones de trabajo, presentaciones o informes era mucho más importante que otra formación técnica o en metodologías específicas. El foco de la supervisión y feed-back de los consultores jóvenes, hasta extremos inconcebibles, era sobre todos los aspectos relacionados con la comunicación y "todo lo que comunica" en la relación con el cliente y el equipo (el vestuario, la posición corporal, los gestos, el diseño de gráficos, tablas, documentos escritos...)".
José Ramón Rodríguez
En PMBOK, cada vez se le da mayor importancia al área de conocimiento de la comunicación. En su última edición, PMBOK (2008), la gestión de la comunicación incluye también la gestión de interesados y se concentra en las etapas de planificación y ejecución, aunque recorre casi todo el conjunto del proyecto:

  • En la etapa de iniciación, con la identificación de las partes interesadas.

  • En la etapa de planificación, con la preparación del Plan de comunicación.

  • En la etapa de ejecución, incluyendo la distribución de la información y la gestión de las expectativas de los interesados.

  • En la etapa de control y seguimiento, con la preparación de los informes de progreso.

Ya se ve que en PMBOK, el planteamiento es posiblemente un poco reduccionista y está muy enfocado a los aspectos formales de reporte y distribución de la información, aunque si se trabaja a lo largo de la última edición del manual, se encuentran aproximaciones y hallazgos de un calado mayor, como veremos seguidamente.
Los procesos de comunicación interaccionan de manera intensa con el resto de los procesos de gestión de proyecto, se superponen entre sí y con los demás y son iterativos. Los procesos, técnicas y herramientas de comunicación no sólo son formales: en el proyecto, todo y todos comunican.

4.1.El proceso de comunicación

El proceso de comunicar tiene muchas dimensiones (PMBOK, 2008), que deben observarse, reconocerse y gestionarse de diferente manera:

  • Comunicación interna (dentro del equipo) y externa (con el cliente, los interesados y otros públicos).

  • Comunicación formal (documentos del proyecto) e informal. La comunicación informal puede ser a su vez oficial o reservada (off the record).

  • Comunicación oral y escrita.

  • Comunicación verbal y no verbal (las inflexiones de la voz, los gestos, la expresión corporal).

  • Comunicación vertical (hacia arriba o hacia abajo) u horizontal (entre iguales).

Asimismo, la comunicación en gestión de proyectos incluye diferentes capacidades, muchas de ellas comunes a la comunicación empresarial o incluso a la comunicación general entre personas, pero que en la gestión de proyectos, con sus consecuencias sobre el trabajo, deben manejarse con especial cuidado y rigor. Son, entre otras, las siguientes (PMBOK, 2008, ampliado):

  • Escuchar activamente.

  • Saber preguntar y proporcionar retroalimentación (feed-back), para asegurarse de que se ha comprendido bien la respuesta.

  • Entender las barreras de comunicación, lenguaje o expresión y buscar maneras de superarlas.

  • Saber elaborar hipótesis y buscar hechos para identificar, confirmar o rechazar la información que necesitamos.

  • Expresar con claridad y honradez el propio punto de vista y defenderlo en una discusión abierta.

  • Establecer las expectativas con claridad y saber manejarlas.

  • Convencer o persuadir y, sobre todo, convertir esa persuasión en acciones.

  • Negociar, para alcanzar acuerdos aceptables entre las partes.

  • Resolver conflictos.

  • Sumarizar, recapitular y preparar los pasos siguientes.

Como veremos en un apartado siguiente, la comunicación también es, por lo tanto, una componente central de otras muchas habilidades interpersonales, que necesita manejar el jefe o gerente de proyecto y los miembros del equipo.
Desde el punto de vista de la comunicación formal y la distribución de información dentro del proyecto, aparece también un conjunto de técnicas y habilidades a adquirir y gestionar, como las siguientes (PMBOK, 2008, modificado y ampliado):

  • Preparación, manejo y documentación de entrevistas.

  • Preparación, manejo y documentación de reuniones.

  • Técnicas de facilitación, para construir consenso y superar barreras.

  • Técnicas de presentación oral.

  • Técnicas de presentación escrita, preparación de informes, gráficos y tablas.

  • Elección de los canales, medios y tecnología más adecuada para comunicar en cada caso.

El modelo básico de comunicación
El modelo básico de comunicación utilizado en todas las ciencias sociales para la comunicación entre dos partes es aplicable también a la comunicación en gestión de proyectos. Según este modelo, en cualquier proceso de comunicación existen los siguientes componentes (figura 4):

  • Un emisor y un receptor.

  • Un codificador, que traduce las ideas en un lenguaje que pueda ser comprendido por las dos partes.

  • Un mensaje de ida y otro de vuelta. Al mensaje de vuelta le llamamos feed-back o retroalimentación, que quiere decir en primer lugar un reconocimiento de que el mensaje se ha recibido y se ha entendido.

  • Un medio o canal a través del cual se trasmite el mensaje.

  • Ruido, o sea, cualquier cosa que interfiere la transmisión y comprensión del lenguaje.

  • Un decodificador, que convierte el lenguaje de nuevo en ideas que puedan ser comprendidas.

Figura 4. El modelo básico de comunicación
Fuente: PMBOK (2008)
Corresponde al emisor asegurarse de que la información se recibe clara y completa y confirmar que se ha entendido. Y corresponde al receptor asegurarse de que ha recibido la información que le han transmitido, de forma completa y clara, y confirmar que lo ha hecho. Para ello se usan técnicas como la repetición y la paráfrasis ("has querido decir que...").
Corresponde a los dos (pero en un proyecto, es una responsabilidad principal del jefe de proyecto) eliminar barreras que introduzcan ruido (rumores, distancia, malos entendidos, problemas tecnológicos...). A veces estas barreras son psicológicas o políticas, producidas por un sesgo de actitud o de interés. Las mayores barreras para la comunicación provienen de "lo que no se dice"; es decir, de la interpretación que hace el receptor del mensaje, basada en sus experiencias anteriores, su actitud o la actitud que percibe o interpreta del emisor, la aparición de códigos diferentes (las mismas palabras que pueden querer diferentes cosas), factores culturales y de posición o interés con relación al proyecto.
La necesidad de comunicación y los riesgos de una comunicación inadecuada aumentan de forma exponencial con el número de personas que comunican entre sí.
Fuentes: PMBOK (2008, pág. 255); Rodríguez, García, Lamarca, (2007, pág. 137)

4.2.Algunas reglas básicas

Acabaremos esta sección con algunos consejos prácticos, que parecen de sentido común, pero que incomprensiblemente se echan a menudo a faltar en la comunicación en los proyectos. Si se siguen estas reglas, las probabilidades de éxito a la hora de comunicar bien son muy altas, incluso si no se conocen modelos o técnicas sofisticadas:
1) No prometas lo que no estás seguro de poder cumplir. Es preferible prometer menos y superar luego las expectativas del cliente.
2) Cumple lo que has prometido y, si sabes que no lo harás, comunícalo pronto. En general, informa cuanto antes de las situaciones, incidencias o cambios que puedan afectar a los resultados del proyecto.
3) Reporta honrada y claramente el estado del proyecto. Prepara bien los materiales y asegúrate de que se presentan con claridad, sencillez y elegancia. Reporta excepciones, cambios y temas sobre los que se debe decidir. Lo demás no importa mucho a nadie.
4) Mantén una confidencialidad absoluta sobre la información del proyecto y del cliente.
5) No pongas por escrito lo que no quieres que alguien lea. No confíes que un documento o un correo no se copiará a quien no deseas, por muy confidencial que tú creas que es.
6) En temas críticos o de conflicto, limita al máximo la comunicación escrita. Confronta a tu interlocutor rápida y directamente, en persona.
7) Sé claro, conciso y específico en el mensaje que deseas trasmitir y en el lenguaje que utilizas. Exprésalo con convicción y emoción.
8) Da y pide activamente retroalimentación para asegurar la comprensión de los mensajes. Al principio, suena raro. Luego, todo el mundo ve las ventajas.
9) Escucha proactivamente. No presupongas. No juzgues. No culpes. Escucha abiertamente la opinión de otros y comparte la tuya con los demás. Básate en los hechos.
10) Es bueno facilitar el consenso y la negociación, pero eso no está por encima de los intereses del cliente y del proyecto.
11) Las reuniones son buenas. Muchas reuniones no son buenas. Son necesarias reuniones cortas, para compartir información, reporte y tomar decisiones, con los objetivos claros y los miembros necesarios según el tema.
12) Prepara con anticipación las reuniones. Haz las convocatorias con anticipación, con un objetivo claro y una agenda con contenidos. Envía la documentación que deba examinarse con antelación. Haz actas con los acuerdos y envíalas a los participantes.
13) Dedica tiempo a preparar cualquier oportunidad de comunicación, como las entrevistas, reuniones, presentaciones e informes. Ensaya.
14) Comprende y acepta las emociones e intereses de todos. Crea un ambiente que facilite su expresión. Observa también el lenguaje no verbal y "lo que no se dice". Calla. Deja hablar. Gestiona los silencios.
15) Comprende y acepta tus emociones y las expectativas y barreras que crean en otros.

5.Habilidades interpersonales

La comunicación en el proyecto, como hemos visto, incluye un conjunto de procesos, técnicas y herramientas, pero también es una habilidad interpersonal que debe desarrollar el jefe de proyecto, principalmente, y el resto de los miembros, tanto para la relación interna dentro del equipo, como para la relación con el cliente, los interesados y la propia organización o empresa en la que uno presta servicios. Seguramente, de todas las habilidades que debe desarrollar el profesional de la gestión de proyectos, la comunicación es la más importante.
Pero no es la única. PMBOK (2008) ha recogido en un apéndice de su última edición un conjunto de habilidades de relación personal, que ayudarán al profesional a entender mejor las situaciones que se producen en el proyecto y a manejarlas adecuadamente. Estas son:

  • El liderazgo.

  • Hacer equipo (team building).

  • La motivación.

  • La comunicación.

  • La capacidad de influenciar.

  • La toma de decisiones.

  • La sensibilidad cultural y política.

  • La negociación.

5.1.El liderazgo

Puede definirse el liderazgo como la capacidad de mostrar una visión y focalizar los esfuerzos de un grupo humano hacia un objetivo común, ayudándoles a trabajar como un equipo. El liderazgo se basa en el respeto, la confianza y el sentimiento de pertenencia al equipo.
El liderazgo se muestra durante todo el proyecto, pero es especialmente importante al inicio del trabajo (cuando el equipo se forma) y, durante la ejecución, en la gestión de las situaciones de conflicto. A lo largo del trabajo, el líder de proyecto es responsable de mantener la visión, la estrategia y la comunicación, generar confianza y hacer crecer al equipo, proporcionar entrenamiento y guía a los miembros y evaluar el rendimiento individual y del conjunto.
Aunque puede haber cualidades innatas que faciliten el liderazgo y personas que no están dotadas o sobresalen en esta capacidad, el liderazgo es una habilidad que se adquiere con la formación, la observación, la supervisión y la madurez en el trabajo.
La tabla siguiente (tabla 5) muestra las características o cualidades de un buen líder de proyecto.
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 5
Cualidades de un buen líder de proyecto
a) Genera confianza y crea sentimiento de equipo. Los miembros tienen un sentido de pertenencia y de que su aportación se reconoce, quieren estar allí y trabajar con los otros. Para esto:

  • Escucha activamente, se interesa por las opiniones de los otros, pide ayuda.

  • Se interesa por los sentimientos y situaciones personales de los miembros del equipo.

  • Reconoce la diversidad de talentos de los miembros y las contribuciones positivas de cada uno.

  • Muestra siempre una actitud positiva, cálida y accesible.

  • Mantiene informado al equipo.

  • No acepta trabajos o retos por encima de las posibilidades del equipo. Consigue recursos y reconocimiento de la organización.

b) Aporta una visión clara. Los miembros entienden lo que se espera de ellos y del equipo. Para esto:

  • Tiene una visión global del proyecto, desde el punto de vista del negocio y de la tecnología, y es capaz de trasmitirla.

  • Establece un plan de trabajo claro, en el que se identifican bien los resultados y se puede medir el éxito. La gente prefiere liderazgos orientados a evaluar resultados globales que a supervisar tareas.

  • Reconoce el trabajo bien hecho, sabe cómo se hace bien y lo sabe trasmitir.

  • Anticipa los problemas y señala pautas para resolverlos.

  • Toma de decisiones y las toma oportunamente
c) Es un buen entrenador (coach) individual, que facilita el desarrollo del equipo y de sus miembros mediante el ejemplo, la comunicación y la evaluación, pero sobre todo consigue que cada persona tome responsabilidad sobre su parte del trabajo y sobre su desarrollo individual en el proyecto.

  • Identifica la situación de cada miembro y sus necesidades e intereses de desarrollo.

  • Ayuda a cada miembro a establecer dentro del proyecto objetivos de desarrollo individual.

  • Reconoce el trabajo bien hecho y el que debe ser corregido, explica el porqué con claridad, sin buscar culpas ni culpables, y facilita que el miembro del equipo desee hacerlo correctamente.

d) Tiene otras "cualidades" (que algunos denominan carisma) que hacen que otros lo reconozcan como líder:

  • Suele ser entusiasta, apasionado y motivador, alguien con quien la gente quiere trabajar.

  • Suele ser creativo, identifica oportunidades donde otros ven problemas y es capaz de innovar sobre la solución de siempre.

  • Suele ser íntegro, mantiene sus promesas, es leal con sus leales y mantiene siempre elevados estándares profesionales y éticos.

  • Lidera con el ejemplo, no con las palabras.
e) Y además, "sabe". En proyectos técnicos y en el mundo de las TIC, un buen líder tiene que aportar también competencia técnica y conocimiento del estado del arte en las tecnologías o temas que son objeto del proyecto, y ser capaz de explicarlos y entrenar a los miembros del equipo.

5.2.Hacer equipo, motivar e influir

El liderazgo, la capacidad de construir y desarrollar un equipo son habilidades que van muy unidas. Hacer equipo (team building, en inglés) es "el proceso de ayudar a un grupo de individuos, unidos por el sentimiento de compartir un mismo propósito, a trabajar de forma interdependiente entre sí, con el líder, con las partes externas al equipo y con la organización. El resultado de un buen liderazgo y de hacer equipo se llama buen trabajo en equipo" (PMBOK (2008), pág. 418). Y buen trabajo en equipo quiere decir confianza mutua, comunicación abierta y efectiva, un mejor proceso de toma de decisiones, control de proyecto basado en la honradez y la confianza y, normalmente, un proyecto mejor gestionado y de mayor probabilidad de éxito.
Hacer equipo, en los proyectos actuales, incluye también a personas del cliente, de los subcontratistas y, eventualmente, de otras partes interesadas, y también con otros miembros de la organización "padre" para la que uno presta sus servicios y que ha sido contratada por el cliente.
Mientras que el liderazgo es principalmente una habilidad y se desarrolla principalmente con la experiencia, las actividades de hacer equipo pueden estar más formalizadas a través de procesos y herramientas. Estas actividades consisten principalmente en la creación, desarrollo y mantenimiento de un entorno de trabajo donde la gente se siente motivada para trabajar como un equipo. Esto incluye, entre las cosas más importantes:
1) Establecer reglas claras de comportamiento (en inglés, ground rules) y una cultura de equipo (estas reglas afectan sobre todo a la comunicación, intercambio de información y a la organización del tiempo y el espacio, además de a los procesos y documentos formales, básicos y compartidos de la gestión del proyecto).
2) Resolver los problemas y conflictos que surjan dentro del equipo.
La gestión de conflictos
El conflicto es inevitable, probablemente es necesario. Un buen diseño de organización, un buen plan, comunicación clara, liderazgo efectivo y sentimiento de equipo reducen los conflictos. Pero hay conflictos.
En principio, para mantener la cultura de equipo, los debe resolver el equipo, sin intervención externa; son los temas de "vestuario" en los equipos de fútbol. Un espíritu y una cultura abierta de comunicación minimiza el conflicto y permite resolverlo con más facilidad. Las culturas anglosajonas no tienen aversión al conflicto, las nuestras normalmente sí.
Buscar culpas y culpables no ayuda a resolver el conflicto, lo agrava y llena al equipo y las personas de malos sentimientos. Se trata de concentrarse en los hechos, no en las personas, y en el presente, no en el pasado. Analizar los temas y sus causas es bueno para no repetir errores, pero sobre todo se trata de establecer las políticas, procesos y necesidades (de organización, de supervisión, de control, de formación, las que sea), para no repetir errores ni conflictos. Y establecer un ambiente positivo que aleje los malos sentimientos.
3) Gestionar el desarrollo del equipo en su proceso de evolución, que, según las teorías de desarrollo de las organizaciones, acostumbra a seguir patrones de comportamiento conocidos.
Las fases de desarrollo del equipo
Según las teorías de desarrollo de la organización, en la construcción y formación de un equipo, se pasa y se debe pasar por cinco fases. Corresponde al director de proyecto observar e identificar el comportamiento del equipo para gestionar la transición de una fase a otra de una manera efectiva y a la velocidad adecuada. Este modelo se llama "la escalera de Tuckman", por ser el autor que lo desarrolló:
1) Formación (forming). En esta fase, el equipo se encuentra por primera vez y aprende los objetivos del proyecto y el rol y responsabilidad individual de cada miembro. El equipo apenas existe, los miembros son independientes y no muy abiertos.
2) Tormenta (storming). A continuación, el equipo comienza a actuar sobre el proyecto, establecer y compartir una planificación, intercambiar información y tomar decisiones técnicas. Si los miembros no colaboran y se abren a diferentes ideas y perspectivas, el ambiente puede ser destructivo y el proyecto puede paralizarse en una fase que es muy crítica.
3) Normalización (norming). En esta fase, el equipo se acostumbra a trabajar junto y ajusta sus hábitos y comportamientos. Comienza a haber confianza entre sus miembros.
4) Rendimiento (performing). En esta fase, el equipo alcanza su ritmo de funcionamiento normal y es capaz de trabajar como una máquina bien organizada. Sus miembros son interdependientes y trabajan en las incidencias y resuelven los temas que salen al paso de forma suave y efectiva.
5) Separación (adjourning). En esta fase, el equipo acaba el trabajo y se va del proyecto a un proyecto nuevo o a su actividad ordinaria en operaciones.
Fuente: PMBOK (2008, pág. 233).
4) Gestión del espacio físico. A pesar del desarrollo de las tecnologías y de la globalización, que permite y obliga al teletrabajo, la cultura de equipo crece cuando se trabaja en el mismo espacio físico.
5) Evaluación. La evaluación puede proporcionarse de muchas maneras. El entrenamiento y supervisión en el trabajo y la retroalimentación inmediata ("esto está bien, estupendo; esto no está bien por este motivo, la próxima vez saldrá mejor") es lo más efectivo dentro del proyecto. Pero además, los miembros del equipo están sujetos a un proceso de desarrollo profesional, del cual el proyecto es una parte o un peldaño relevante. Por lo tanto, deben recibir un plan de los objetivos y lo que se espera de ellos en el trabajo y una o varias evaluaciones de su desempeño.
6) Reconocimiento y recompensas. El plan de recursos humanos y las reglas de la compañía "madre" deben permitir que el líder de proyecto establezca objetivos asequibles, medibles y controlables, que estén al alcance de todos los miembros y por los que puedan ser recompensados (en particular, en su carrera profesional, la asignación de proyectos y la retribución). Es difícil mantener el sentimiento de equipo y la motivación si las políticas y procesos de recursos humanos no recompensan el cumplimiento de objetivos y conductas deseables y que cualquier miembro del equipo (y no unos pocos, o su jefe) pueden alcanzar.
Estos dos últimos temas (evaluación y reconocimiento) son complejos en las grandes organizaciones profesionales o empresas de servicios TIC. Por un lado, el líder de proyecto intenta desplegar los mejores instrumentos y habilidades para generar un equipo de alto rendimiento, cohesionado y que disfrute en el proyecto. Por otro, algunas de las herramientas básicas de motivación no están en su mano o incluso, en el límite, pueden ser contradictorias o contraproducentes.
Motivar es lograr el compromiso de los miembros del equipo con los resultados del proyecto, con su rol dentro del mismo y con el resto de los miembros. Para ello, se trata de entender qué cosas ofrecen a cada persona mayores satisfacciones o cuáles son las que cada uno valora más.
Estos valores suelen ser la satisfacción en el trabajo, los retos progresivos dentro de su carrera y dentro del proyecto, un sentimiento interior de autorrealización y de contribución al proyecto y al equipo, sentimientos de crecimiento profesional y personal, la compensación económica y la promoción en la escala laboral y otra clase de recompensas o reconocimientos a veces morales o psicológicos.
Los motivadores varían con la edad, las diferencias culturales, la posición de partida y hasta qué punto estén resueltas las necesidades más básicas, según la célebre pirámide de Maslow.
La pirámide de Maslow
Abraham Maslow (1908-1970) es famoso por su teoría de las necesidades humanas. En su visión, las necesidades humanas pueden agruparse en cinco categorías jerárquicas ascendentes. Cuando una categoría de necesidades queda satisfecha, deja de ser un motivador, que se sustituye por la categoría siguiente y así sucesivamente.
Los cinco niveles de necesidades, comenzando por las más básicas, son las siguientes:
1) Las necesidades fisiológicas y de supervivencia, como comer, beber, tener una vivienda, vestirse y dormir.
2) Las necesidades de seguridad y de protección frente al peligro, como tener un trabajo y un sueldo para vivir.
3) Las necesidades sociales, que incluyen el sentimiento de pertenencia y aceptación por el grupo.
4) Las necesidades del Yo, la autoestima y el reconocimiento social, a través de la confianza en uno mismo, el poder o el prestigio.
5) Las necesidades de crecimiento personal, es decir, el deseo de aumentar las propias capacidades, talentos y experiencia, intelectual, emocional o profesional. Este grupo lleva asociados los sentimientos de autorrealización, autoexpresión y autocumplimiento.
A diferencia del liderazgo formal basado en la autoridad jerárquica, el trabajo en equipo entre profesionales de alta cualificación formados en ámbitos técnicos específicos, como son los de las TIC, suele pedir un tipo de liderazgo y motivación basado en la capacidad de hacer un buen trabajo técnico, en retos de complejidad creciente y variada en un entorno especializado, en el reconocimiento de sus iguales y en el respeto y confianza hacia las personas que les supervisan. Son los "trabajadores del conocimiento" a los que se refería Peter Drucker y suelen sentirse más comprometidos con su profesión y con el contenido técnico de su trabajo, que con la organización a la que sirven, con el cliente, con el proyecto o con el propio equipo. Son individualistas y sensibles. A cambio, suele ser personal muy entregado y automotivado por lo que hace, si lo que hace le interesa, bastante leal y le gusta establecer relaciones a largo plazo. El líder de proyectos TIC tiene que tener muy en cuenta estas características.
El liderazgo en proyectos TIC se muestra más a través de la influencia y el reconocimiento que a través de la autoridad y los procesos formales. La influencia se muestra liderando a través del ejemplo, haciéndose respetar en su propia área de conocimiento y experiencia (los profesionales respetan a los profesionales y desprecian a los incompetentes), usando un estilo de dirección flexible y ajustado a cada tipo de público, clarificando el proceso de toma de decisiones y el por qué de una decisión determinada y siendo cuidadoso en las formas. Es necesario apostar por la relación a largo plazo y no dejar que se deteriore por un conflicto o un desentendimiento puntual.

5.3.La toma de decisiones y resolución de problemas

Issues, cambios, riesgos... son problemas y oportunidades para el gerente, que requieren su intervención (o a veces, una decisión deliberada de no intervenir y dejar que sea el propio equipo el que resuelva el problema). Ejecutar es eso: decisión, acción. El jefe de proyecto puede tomar las decisiones individualmente o involucrar al equipo, según su estilo de dirección y las reglas de comportamiento (ground rules) explícita o implícitamente establecidas, pero no es conveniente cambiar de criterio según le convenga.
En todo caso, las decisiones están influidas por factores de tiempo, calidad de la información con la que se cuenta, confianza o confiabilidad de sus fuentes y criterios de aceptación o aceptabilidad.
Es bueno que el plan de proyecto y sobre todo los aspectos de organización del trabajo que hemos comentado en este módulo (la asignación de roles, responsabilidades y autoridad en órganos individuales o colectivos) establezcan con claridad quién puede decidir sobre qué, cuándo y cómo.
Por lo tanto, aquí nos referiremos a aquellas decisiones que afectan a aspectos del proyecto distintos de la resolución de incidencias ordinarias del día a día y sobre las que el líder de proyecto tiene autoridad para decidir o para proponer a un órgano superior.
La toma de decisiones y solución de problemas en proyectos complejos no es una actividad intuitiva ni una intervención de emergencia, o hay que intentar que no sea así, lo máximo posible. Decisiones tomadas precipitadamente, ante problemas mal definidos, sin la información relevante y el análisis y consultas adecuadas, y sin la evaluación de su impacto sobre el proyecto, suelen conducir al error y minan la confianza del equipo y del cliente en el jefe de proyecto.
El ciclo de toma de decisiones debería responder a la siguiente secuencia de actuación (figura 5).
Figura 5. Secuencia de toma de decisiones en un proyecto
Fuente: Rodríguez, García, Lamarca (2007)
1) La definición del problema o la oportunidad, es decir, la identificación o reconocimiento de la necesidad, en forma de problema u oportunidad. Esta necesidad resulta del gap o diferencia entre aquello que se hace o pasa (problema) y lo que se planificó en su día, y entre aquello que se podría hacer (oportunidad) y lo que se planificó en su día.
2) La búsqueda y el análisis de la información disponible. Cualquier toma de decisiones requiere un proceso de búsqueda selectiva de la información relevante que detalle la oportunidad o el problema que hay que resolver. Es bueno que este proceso, para que no consuma excesivos recursos y esté enfocado, se guíe desde una generación de las hipótesis más probables (hipothesys driven), de manera que sólo tendremos que buscar aquella información que permita validar o rechazar nuestra hipótesis.
3) El desarrollo de escenarios de evolución de la situación de necesidad permite analizar cuál puede ser la evolución futura del problema o la oportunidad y, por lo tanto, tomar decisiones basadas en su probable evolución. Se trata de cualificar y cuantificar la dimensión del problema. Frecuentemente, algo que parece un problema no lo es o simplemente se resolverá solo.
4) La definición de decisiones alternativas permite determinar todas las posibles actuaciones ante la necesidad analizada o las más importantes. Éste es un ejercicio de creatividad en el que se busca encontrar el máximo de respuestas alternativas posibles. Esto es útil porque desincentiva la toma de decisiones precipitadas, proporciona seguridad al líder y al grupo y ayuda a generar consenso.
5) El análisis de implicaciones y la valoración de cada alternativa contempla el estudio del impacto y la viabilidad de cada una de las mismas. El establecimiento previo de criterios de valoración (pros y contras) de las ideas generadas permite considerarlas en función de la capacidad de respuesta ante la necesidad y de los intereses generales del proyecto y de la organización. Es el proceso de llevar las ideas de la teoría a la acción (ideas to action) que a veces elimina por sí mismo algunas decisiones descabelladas.
6) La selección de la mejor alternativa implica la toma de decisión final sobre el problema u oportunidad y el desarrollo de la decisión para que ésta pueda ser implementada. No hay decisión ni solución sin un plan de acción, que debe implicar a todos los participantes clave (ahora sí), para obtener aceptación y compromiso. Si no, nada pasará. En este momento, deben modificarse también los planes o líneas base de proyecto, si fuese el caso.
7) La implementación de la alternativa implica el compromiso de recursos y la realización de las actividades marcadas. El paso a la ejecución es crítico, especialmente en proyectos TIC. El líder de proyecto tiene que vigilar especialmente los primeros pasos. La técnica de "¿cuál es el paso siguiente?" y su monitorización suele funcionar.
8) La evaluación de los resultados supone el análisis de resultados de la decisión sobre la necesidad que se había identificado. Esta evaluación incluye el análisis de la implantación de la solución acordada, pero también del proceso seguido para la toma de decisiones. Y aprender de ambos.
Tomar decisiones tiene una parte de proceso estructurado (el que hemos presentado más arriba), otra parte de análisis de la información disponible, otra parte de generación de ideas y consenso entre aquellos que tendrán que ejecutarlas y otra parte de intuición, arte y experiencia. Es la toma de decisiones lo que suele distinguir a los buenos jefes de proyecto de los no tan buenos y la mejor fuente de conocimiento es la propia experiencia, los errores y aciertos cometidos en momentos anteriores y el aprendizaje a partir de esos aciertos y errores (tabla 6).
Fuente: Rodríguez, García, Lamarca (2007)
Tabla 6
Características de la toma de decisiones en un proyecto

  • Todas las decisiones suponen riesgos e incertidumbre.

  • Es necesario disponer de información adecuada para tomar decisiones en un proyecto, pero puede llegar un momento en el que quizá sea preciso parar la búsqueda y tomar la decisión para seguir adelante.

  • El gerente de proyecto debe disponer del conocimiento, habilidades, y actitud para tomar una decisión en representación del proyecto y la organización del mismo.

  • Muchas veces, es necesario el consenso dentro del equipo y el apoyo de los agentes implicados.

  • Las decisiones pueden tener implicaciones operativas (corto plazo) y estratégicas (largo plazo).

  • El gerente de proyecto tiene la responsabilidad de tomar e implementar las decisiones que involucren la utilización de recursos. Cuando la decisión sobrepase su responsabilidad, debe avisar e involucrar a las instancias superiores que se requieran.

  • Antes de cualquier decisión, el gerente debería solicitar consejo a las personas de su equipo y agentes involucrados.

  • Las decisiones de proyecto nunca deben tomarse antes de analizar y evaluar los obstáculos y opiniones adversas.

  • Para cualquier proyecto, una alternativa posible es siempre no actuar.

  • Sin embargo, siempre hay que actuar cuando la situación puede degenerar si no se hace nada.

  • Cualquier decisión que se tome debe conseguir el compromiso del equipo para hacerla realidad.

5.4.Sensibilidad política y cultural

Como hemos señalado en el apartado dedicado a la gestión de interesados, la política dentro de las organizaciones es algo inevitable, debido a las condiciones de asignación de recursos escasos, las prácticas de negociación y los conflictos de posición e interés, incluida la defensa de los intereses del propio grupo frente a otros o incluso frente al interés general en determinados casos. El líder de proyecto no puede ignorar estos elementos sino observarlos con realismo e intervenir a través de una serie de técnicas de análisis y de gestión que ya hemos tratado en aquel apartado. Los proyectos, especialmente los proyectos complejos y mixtos (que involucran la aplicación de las TIC al negocio), representan alteraciones del statu quo, de los equilibrios de poder y de las costumbres y formas de hacer.
Cuando hablamos de cultura, estamos hablando de muchas cosas distintas. Para PMBOK (2008) y los manuales anglosajones, las "diferencias culturales" remiten a la diversidad de lenguas, costumbres, creencias, comportamiento en el trabajo y maneras de trabajar que ocurren en diferentes zonas y países del mundo. Les preocupa que estas diferencias puedan tener un impacto sobre la velocidad y productividad del trabajo, la manera de gestionar la comunicación y los conflictos y los procesos de toma de decisiones. En su opinión, una buena planificación del proyecto (en especial, los aspectos de comunicación y organización), el conocimiento personal entre los miembros clave del equipo y el recurso a los manuales sobre diferencias culturales (cómo trabajan los chinos o los alemanes o los españoles) deben solucionar esta clase de inconvenientes en una economía global.
Sin minusvalorar este aspecto, nos interesa más aquí exhortar a que el líder del proyecto y los miembros hasta donde sea posible entiendan las características "culturales" de la organización en la que se desarrolla el proyecto, de los clientes y de sus diferentes grupos de interés.
Las culturas y estilos de trabajo del cliente, los interesados y los miembros del equipo (y contratistas) pueden tener una fuerte influencia en la capacidad del proyecto para cumplir sus objetivos.
La cultura quiere decir, en este sentido más restringido, un conocimiento y comportamiento compartido (unas "normas" o reglas de actuación) sobre cómo se hace el trabajo, qué se considera aceptable y qué no, y quién es formal o informalmente influyente para hacer que el trabajo se haga. La cultura afecta también a las normas de comunicación interna y otros "activos" de la organización en los que el proyecto debe convivir.
Los más importantes son:

  • La visión y valores, lo que podríamos llamar la "filosofía" de la empresa: cuál es su aspiración ante la sociedad, de sus clientes, proveedores y empleados. Cuál es su "ética", las creencias y maneras de comportarse que la empresa piensa y trasmite en palabras y en hechos que están bien y que no están bien.

  • Las políticas, métodos y procedimientos, "nuestra manera de hacer las cosas".

  • Las relaciones de autoridad, formales e informales. Quién manda, prescribe o influye, con independencia de lo que diga el organigrama. Cuáles son los circuitos de información y comunicación.

  • La ética del trabajo, dedicación, calidad y horarios.

  • El ambiente de trabajo y el tipo de comunicación. Esto incluye la organización física, los desplazamientos, la velocidad de movimientos, el tono de voz, los gestos, la actitud en las entrevistas y reuniones...

  • Los sistemas de reconocimiento, recompensa y promoción. Qué es lo que la empresa premia, a quién y por qué.

Todos estos elementos muchas veces no están explicitados o, cuando lo están, puede haber una contradicción entre lo que se dice o está escrito y lo que ocurre en la realidad. Es parte de la sensibilidad y la experiencia del jefe de proyecto entender la cultura "real", con independencia de la cultura oficial. Si el interlocutor o jefe de proyecto interno designado por el cliente tiene una comunicación abierta y hace equipo con nosotros, esta comprensión es mucho más fácil. A veces, es útil identificar entre los interesados o entre los miembros del equipo por parte del cliente alguna persona que pueda aportar esta visión. Y con mucha frecuencia, los miembros de nuestro equipo que están sobre el terreno y conocen a muchos miembros de la organización nos pueden dar una visión más exacta de la que el jefe de proyecto puede adquirir a través de sus relaciones con el personal directivo.
El proyecto (si es suficientemente grande, complejo, multidepartamental y si impacta al negocio, como ocurre casi siempre) será un elemento extraño dentro de la "cultura" de la organización. El líder de proyecto debe valorar con el cliente y los interesados, cuánto "cambio" está dispuesta a asumir la organización y colaborar con la empresa en la gestión de esos cambios.

5.5.La negociación

La negociación, como los conflictos, es una parte central de la gestión de proyectos, pero muchas veces ni se trata en la literatura académica, ni en los manuales prácticos ni el propio profesional, el jefe de proyecto, es consciente de que cada día, en cada momento, está negociando.
Se negocia con el cliente, los interesados, los contratistas y dentro del equipo. Un buen líder de proyecto es un buen negociador. Negociar mal es apostar por el fracaso del proyecto y minar la confianza del equipo y del cliente.
Muchas de las bases teóricas de la negociación pueden encontrarse en nuestro análisis de la gestión de interesados en un apartado anterior. La negociación se basa en que todo el mundo tiene algo que defender, una parte propia de interés que puede ser contradictoria con la de otra parte o con la del proyecto en conjunto. También se basa en que el proyecto es largo y necesita del mayor número de apoyos. Por tanto, en gestión de proyectos, la mala negociación es la que se basa en decir siempre que no, en querer ganar siempre y sentirse orgulloso de las victorias en conflictos puntuales. En cambio, la buena negociación se basa en defender los intereses del cliente y del proyecto a largo plazo, en establecer relaciones colaborativas y, por lo tanto, en buscar situaciones en las que todos ganen un poco y pierdan un poco (lo que se llama win-win).
La buena negociación es estratégica, el buen negociador elige los conflictos y evita las batallas inútiles o que no puede ganar. También debe elegir y marcar, si puede, las formalidades y ritmos de la negociación. En negociaciones formales, como las que se hacen para ganar un contrato, una ampliación de proyecto, reconocer una desviación que está en discusión o una revisión del alcance, cambiar los liderazgos o responsabilidades dentro del equipo propio o del cliente..., es bueno disponer de una buena estrategia y seguir un proceso ordenado.
La secuencia de una buena negociación suele ser la siguiente:
1) Analizar la situación. Entender bien los temas y las áreas que serán objeto de negociación. No es aún el momento de determinar qué se quiere obtener, cuál es el resultado deseado. No hay prisa. Tampoco hay que pensar en las posiciones de unos y de otros. Hay que analizar los hechos y los temas, sin pasión. Es bueno producir un documento donde se presenten los temas de conflicto y los de acuerdo, que podría compartirse con el cliente llegado el caso.
2) Entender también la situación de los diferentes interesados y partes que intervienen en la negociación, sus intereses y la situación emocional del proyecto y de las partes. También los nuestros y los de nuestra empresa. Y lo más importante, quién tomará la decisión, quién es el que tiene que comprar el acuerdo (y, en su caso, a quién tiene que convencer).
3) Definir entonces los diferentes objetivos que queremos obtener y ponerlos en orden, cuál es nuestra prioridad (volumen, precio, tiempo, tener una referencia, reducir el riesgo...) entre todos ellos, el objetivo más importante. Y para cada uno de los temas en discusión, podemos entonces definir cuál es nuestro objetivo deseado (nuestro techo de satisfacción) y cuál es el mínimo aceptable (nuestro umbral de satisfacción).
4) Ahora podemos tratar de imaginar lo mismo de la otra parte. Y probablemente ya nos lo ha dicho o nos lo dirá, pero es posible que no explique sus prioridades ni el peso que tiene cada una, aunque podemos intentar preguntarle. En una negociación entre socios, a largo plazo y que tiene que conducir al acuerdo (que es el tipo de negociación que defendemos en gestión de proyectos TIC), cuanto más se muestren las cartas, mejor será para todos. Qué es lo que le importa, y qué le importa más.
5) Antes de seguir, conviene hacer un análisis tipo DAFO (debilidades-amenazas-fortalezas-oportunidades) de las dos partes ante la negociación, para tener una aproximación realista de dónde está cada uno y planificar el estilo y contenido de la negociación.
6) Seguidamente, vale la pena hacer un ejercicio de cruce entre nuestros intereses para cada tema y los de la otra parte, para encontrar o inventar situaciones de win-win. Entender los intereses de la otra parte (qué quiere, por qué lo quiere, para qué lo quiere) es lo más importante de una negociación racional y basada en intereses. También es bueno, a veces, abrir la negociación a otros temas o áreas que pueden ser de interés de la otra parte, aunque no se hayan expresado. Eso puede en ocasiones desbloquear negociaciones muy cerradas o agotadas.
7) Durante la negociación, es bueno ceñirse a un guión que cubra los temas uno a uno y no dispersarse. Es bueno escuchar y argumentar sobre los temas al punto. Es bueno ser duro en la posición (pedir mucho y ofrecer poco y no ceder fácilmente; gesticular que cada concesión cuesta mucho), pero suave, cauto y amistoso en la relación con las personas. En todo caso, insistimos, la posición no es lo más importante: lo importante son los temas y los objetivos estratégicos, la relación a largo plazo y un acuerdo razonable y duradero, que no deje dañado a nadie.
8) Si un tema se bloquea y es imposible avanzar, es preferible dejarlo para otro momento y pasar al siguiente o suspender la reunión y dejar la discusión para otro día, buscar un tiempo de frialdad y también un espacio para encontrar soluciones creativas o para celebrar encuentros formales o informales fuera de la mesa de negociación. En muchas negociaciones, suele ser más importante lo que pasa fuera de la mesa que lo que pasa dentro.
9) Al final de la negociación, las dos partes deben sentirse ganadores y escenificarlo. Es bueno documentar pronto las conclusiones, dejando los temas abiertos para una reunión posterior. Es bueno celebrar el acuerdo de una forma relajada, en especial si la negociación ha sido dura.
Un resumen de este proceso se muestra en la figura 6.
Figura 6. Fases del proceso de negociación

6.La gestión y desarrollo de las personas

De nuevo, la gestión y desarrollo de los miembros del equipo de proyecto tiene dos clases de componentes:
1) Los componentes que hemos llamado soft, y que tienen que ver con el desarrollo de capacidades y habilidades de liderazgo, construcción de equipos, comunicación, motivación y otras, que hemos analizado en los apartados anteriores.
2) Los componentes que hemos llamado hard, es decir, las políticas y procesos de reclutamiento, asignación, desarrollo, formación y recompensa.
En la práctica, las habilidades interpersonales no pueden sustituir ni mejorar las políticas y procesos, sobre los que además el líder de proyecto suele tener normalmente una influencia limitada, ya que dependen casi siempre de una parte de la organización (sea interna o externa) en la que el líder y los miembros del equipo sirven y, en ocasiones, incluso de varias organizaciones distintas. La gestión de esa área no suele estar en manos de los profesionales de línea (los que hacen proyectos) sino de especialistas (los departamentos de recursos humanos) que normalmente jamás han hecho un proyecto. Idealmente, debería existir un alineamiento entre políticas, procesos, habilidades y las prácticas de gestión del proyecto, pero eso no se produce suavemente.
¿Sobre cuáles de estos componentes puede tener el líder de proyecto una influencia mayor y qué clase de políticas y prácticas puede poner en acción? Este será el objeto de las siguientes reflexiones, que deben completarse con las observaciones contenidas en el resto del módulo, en particular en los apartados de habilidades interpersonales y comunicación.

6.1.Los procesos de gestión de recursos humanos en el proyecto

Recordemos en primer lugar el espacio de los procesos de gestión de personas en el proyecto. Según PMBOK (2008), la gestión de los recursos humanos es un "área de conocimiento" separada, que está presente principalmente en dos etapas del proyecto:
a) Durante la planificación se prepara también (aunque no se hace siempre) un plan de recursos humanos, que incluye dos clases de productos:

  • El modelo de organización del proyecto (roles, responsabilidades y organigrama), al que nos hemos referido en un apartado anterior de este módulo.

  • El plan de asignación de recursos (staffing plan), donde se reflejan los requisitos de personas que tiene el proyecto, en cantidad y calidad, y el momento de su incorporación y salida del proyecto, así como sus necesidades de entrenamiento y criterios de evaluación y recompensa.

b) Durante la ejecución, se producen los procesos principales de gestión de las personas individuales y del equipo en su conjunto, que son de tres clases:

  • La asignación efectiva de las personas al proyecto, en función de su disponibilidad.

  • El desarrollo del equipo en el día a día, incluida la evaluación de su rendimiento.

  • La gestión del equipo en el día a día, con las actividades de formación y construcción del equipo, gestión de conflictos, motivación, etc.

¿En qué procesos y de qué manera puede actuar el líder de proyecto de manera efectiva, aparte del despliegue de sus habilidades personales e interpersonales y de su experiencia, que hemos analizado en los apartados anteriores?
1) Puede y debe hacer un buen Plan de gestión de recursos humanos, detallado y documentado, y revisarlo al inicio del trabajo o de las diferentes fases, con la incorporación efectiva del equipo realmente asignado. La mayor parte de los jefes y directores de proyecto no lo hace, más allá de una hoja de cálculo que refleja las cargas de trabajo y los niveles de experiencia requeridos.
2) Puede y debe hacer un buen modelo de organización del proyecto, utilizando la matriz de roles y responsabilidades, tanto en el nivel de hitos como en el de las actividades, clarificando el papel de cada miembro y lo que se espera de él, y asegurando el cruce entre las capacidades individuales y su contribución más efectiva al trabajo. Debe comunicarlo colectiva e individualmente. Este proceso es de los que consideramos básico en la gestión del proyecto.
3) Puede negociar con los departamentos de recursos humanos, operaciones, staffing o con otros jefes de proyecto la incorporación de los perfiles y las personas que verdaderamente necesita para el éxito del trabajo. Puede utilizar su influencia y red de contactos y relaciones y su prestigio delante de los equipos y de la organización.
4) Puede y debe asegurar que tiene sentido para cada persona la asignación a ese trabajo, cómo puede contribuir y crecer profesionalmente y cuáles son sus objetivos y necesidades de desarrollo. Debe fijarlos (en colaboración con el departamento de recursos humanos, con su tutor o mentor, o con la figura que tenga la empresa para ejercer esta función de tutela y acompañamiento del desarrollo de cada profesional) y establecer las métricas e hitos de control.
5) Debe proporcionar feed-back y reconocimiento en el día a día (qué está bien, qué debe mejorar) y evaluación continua. Debe asegurar su formación en el trabajo, programar su participación en las actividades de formación fuera del trabajo y asegurar su asistencia.
6) Debe completar las evaluaciones (assessment) programadas en tiempo y forma, como un diálogo que tiene contenido y valor para las dos partes, y no como un trámite burocrático que hay que cumplir para el departamento de recursos humanos.
7) Debe asegurar que se cumplen las políticas de recompensa establecidas de antemano y defender la posición de los miembros de su equipo en los procesos de evaluación, recompensa y promoción corporativos.
El líder de proyecto tiene una posición delicada. Por un lado, se debe al proyecto y al equipo, y va en ello su crédito: los anglosajones dicen que tan importante como el leadership (la capacidad de liderar) es el followership (la voluntad de ser liderado). Para ello tiene que conseguir recursos y hacer respetar el proyecto ante la organización. Los profesionales TIC valoran especialmente este rol. Si alguien no les asegura recursos y respeto, no les sirve.
Por otro, tiene que asegurar el seguimiento de las políticas y procesos de la organización a la que pertenece y a la que pertenecen sus miembros (y también la del cliente). No es el cabecilla de una guerrilla aislada en territorio enemigo, sino el representante y la cabeza visible de una empresa (si se trata de un contratista externo) o un cargo intermedio o superior de la propia organización (si es un proyecto realizado con recursos propios).

7.Resumen

Un proyecto es un esfuerzo de personas y es el manejo de las personas lo que lo conduce o no, al final del día, al fracaso o al éxito. Así es dentro del equipo de trabajo y en la relación con el cliente, los usuarios y los contratistas. Las causas principales de fracaso de los proyectos no tienen que ver con la tecnología o con la capacidad de producir buenos entregables de informática, telecomunicaciones o multimedia, sino con la gestión de las relaciones entre las personas, dentro y fuera del proyecto.
Una aproximación a la gestión de personas dentro de la gestión de proyectos no debe ser un enunciado de buenos propósitos, sino una disciplina en sí misma en la que deben alinearse, para tener éxito, varias clases de elementos:
1) El diseño de la organización del proyecto, es decir, la clarificación de los roles y responsabilidades de sus miembros, en particular en los niveles de dirección, por parte del cliente y del equipo.
2) La gestión de los interesados (stakeholders), es decir, la identificación inteligente del impacto e influencia del proyecto sobre las diferentes partes de la organización, su predisposición a la adopción y las estrategias a desplegar.
3) Los procesos de comunicación, formal e informal, con relación a las partes interesadas y dentro del equipo, es decir, la gestión de los mensajes, medios, formatos, estilos, portavoces, periodicidad, etc.
4) La gestión y desarrollo de las personas individuales que forman el equipo y del equipo en su conjunto y, por lo tanto, las políticas y procesos de reclutamiento, asignación, desarrollo, formación y recompensa.
5) Las habilidades interpersonales que deben desarrollar los miembros del equipo y, sobre todo, el director o jefe de proyecto, en particular las de comunicación, toma de decisiones, liderazgo, motivación, trabajo en equipo, negociación y resolución de conflictos.
Finalmente, llamamos gestión del cambio (y no, ya lo dijimos, la gestión de los cambios en el alcance o en otras dimensiones del proyecto) a todas aquellas cosas que deben producirse en el cliente para que el proyecto tenga éxito. Esto incluye, asimismo, una comprensión clara de la misión del trabajo desde un punto de vista del negocio, el liderazgo y compromiso de la dirección (mostrado en las decisiones difíciles y la asignación de recursos) y acciones sobre la organización (roles y responsabilidades), los procesos de gestión y, muchas veces, los recursos humanos (en cantidad y calidad). E incluye un proceso activo y sistemático de manejar el cambio para que las cosas que tienen que pasar, pasen.
Lo que llamamos "el lado humano" de la gestión de proyectos incluye dos clases de elementos:

  • Aspectos de estructura, organización, y procesos (sistemas), que pueden afectar al organigrama (del proyecto y de la empresa), a los roles y responsabilidades, las retribuciones o la promoción de las personas, dentro del proyecto, de la empresa proveedora de los servicios o del cliente. Llamamos a estos aspectos la parte "dura" (hard).

  • Aspectos de procesos de gestión del proyecto formales (como la distribución de la información y la identificación y gestión de interesados), habilidades interpersonales que pueden adquirirse y desarrollarse (las habilidades de comunicación, motivación, o toma de decisiones) y aspectos que afectan a la "cultura" del proyecto o del cliente, y sobre los que cada vez existe una mejor información e investigación. Decimos que estos aspectos son la parte blanda (soft).

Todos estos componentes deben estar alineados entre sí y, además, las actuaciones sobre los componentes soft no pueden sustituir a las actuaciones sobre los componentes hard, ni dentro del proyecto ni en el cliente. No podemos motivar con nuestras mejores habilidades de influencia a un miembro del equipo asignado inadecuadamente o mal pagado. No podemos hacer que los usuarios usen un sistema informático sin determinados cambios en sus hábitos de trabajo o en las operaciones, por poner un ejemplo.

7.1.Organización del proyecto

La definición del organigrama del proyecto y de los roles, responsabilidades y autoridad de sus miembros es un proceso completamente básico de la gestión de proyecto.
Aconsejamos que se plasme en una matriz de roles y responsabilidades (REM o RACI), como uno de los documentos básicos de la planificación de proyecto y que se actualice con la incorporación o salida de los miembros. La matriz debe prepararse a nivel de los hitos o EDT y de las actividades, y en ella debe constar, al menos, quién tiene la responsabilidad de ejecución de una tarea, quién tiene la responsabilidad o autoridad sobre la misma, quién debe participar o ser consultado y quién debe estar informado.
Los principales órganos de gestión del proyecto son:

  • El patrocinador o sponsor.

  • El director, jefe, gerente o líder del proyecto.

  • El comité de dirección.

El jefe de proyecto es el responsable del proyecto en el día a día. Tiene que organizar el trabajo dentro del equipo de proyecto y en sus relaciones con la organización cliente. Es la persona que dirige el proyecto desde la planificación hasta el cierre (a veces interviene también en las fases anteriores), y tiene la responsabilidad del cumplimiento de objetivos en tiempo y costes, y de los recursos asignados para ello. Para cumplir con éxito su función, debe estar investido de la autoridad equivalente a su responsabilidad.

7.2.Gestión de interesados

Los interesados (o stakeholders, en inglés) en un proyecto son todas las personas y organizaciones que se verán afectadas por el desarrollo del proyecto, sea directamente, porque participan en el proyecto de alguna manera, o indirectamente, porque el funcionamiento del producto o servicio que resultará del proyecto les afectará de una forma u otra. (La gestión de interesados es una parte importante de la "gestión del cambio".)
A lo largo del proyecto, la gestión de interesados aspira a identificarlos correctamente, entender sus expectativas e interés en el proyecto, calificar su influencia dentro de la organización y establecer estrategias para su manejo para facilitar la participación de aquellas personas que son necesarias para el éxito y, en general, la aceptación del proyecto y los productos o minimizar las barreras de adopción en el seno del cliente. Esto no es sencillo, porque entre las partes existen frecuentemente intereses en conflicto latentes o explícitos, que el proyecto hace más evidentes.
El líder del proyecto no puede ignorar las dimensiones políticas de cualquier proyecto, sino que tiene que identificarlas y manejarlas adecuadamente, utilizando herramientas, técnicas y habilidades variadas, sobre todo, pero no únicamente, las de comunicación.
Un aspecto crucial de la gestión de interesados es el que tiene que ver con el proceso de adopción y uso efectivo de la tecnología por parte de los usuarios internos o externos, una de las razones más frecuentes de fracaso de los proyectos a largo plazo. Es importante estudiar el proceso social e individual de adopción y actuar adecuadamente sobre los grupos de adoptantes y sobre la velocidad de adopción a través de diferentes estrategias y técnicas.

7.3.Comunicación

La comunicación es central en el proceso de gestión de proyectos y afecta a todos los procesos y áreas de conocimiento. Si gestionar un proyecto es gestionar la relación con las personas (el cliente, el equipo, la organización en la que servimos), la relación con las personas se basa en la comunicación.
La gestión de la comunicación incluye procesos de gestión formales (la planificación de la comunicación, la preparación de informes y la distribución de la información) que hemos estudiado en otros módulos y requiere el aprendizaje, desarrollo y despliegue de un conjunto de técnicas y habilidades, como las siguientes:

  • Preparación, manejo y documentación de entrevistas.

  • Preparación, manejo y documentación de reuniones.

  • Técnicas de facilitación, para construir consenso y superar barreras.

  • Técnicas de presentación oral.

  • Técnicas de presentación escrita, preparación de informes, gráficos y tablas.

  • Elección de los canales, medios y tecnología más adecuada para comunicar en cada caso.

En este módulo, hemos estudiado el modelo básico de comunicación entre dos personas y un conjunto de buenas prácticas y recomendaciones para comunicar bien, entre las que destacan la escucha activa, la retroalimentación y la planificación y preparación de los procesos más formales de comunicación (entrevistas, reuniones, presentaciones, informes, etc.).

7.4.Habilidades interpersonales

Habilidades interpersonales
Junto con la comunicación, el líder de proyecto debe aprender, entrenar y desplegar un conjunto variado de habilidades interpersonales para ser efectivo como líder y para conducir con éxito el proyecto. Las más importantes son:

  • El liderazgo. Puede definirse el liderazgo como la capacidad de mostrar una visión y focalizar los esfuerzos de un grupo humano hacia un objetivo común, ayudándoles a trabajar como un equipo. El liderazgo se basa en el respeto, la confianza y el sentimiento de pertenencia al equipo. El liderazgo se muestra durante todo el proyecto, pero es especialmente importante al inicio del trabajo (cuando el equipo se forma) y, durante la ejecución, en la gestión de las situaciones de conflicto. A lo largo del trabajo, el líder de proyecto es responsable de mantener la visión, la estrategia y la comunicación, mantener la confianza y hacer crecer al equipo, proporcionar entrenamiento y guía a los miembros y evaluar el rendimiento individual y del conjunto.

  • Hacer equipo. Hacer equipo (team building, en inglés) es "el proceso de ayudar a un grupo de individuos, unidos por el sentimiento de compartir un mismo propósito, a trabajar de forma interdependiente entre sí, con el líder, con las partes externas al equipo y con la organización. El resultado de un buen liderazgo y de hacer equipo se llama buen trabajo en equipo" (PMBOK, 2008, pág. 418). Y buen trabajo en equipo quiere decir confianza mutua, comunicación abierta y efectiva, un mejor proceso de toma de decisiones, control de proyecto basado en la honradez y la confianza y, normalmente, un proyecto mejor gestionado y de mayor probabilidad de éxito. Las habilidades de hacer equipo se muestran particularmente a la hora de establecer reglas claras de comportamiento en equipo, gestionar los conflictos, acompañar al equipo a lo largo de sus fases de desarrollo (desde un grupo de personas independientes a un equipo cohesionado de personas interdependientes), evaluar a las personas y reconocer y recompensar el trabajo bien hecho.

  • Motivación. Motivar es lograr el compromiso de los miembros del equipo con los resultados del proyecto, con su rol dentro del mismo y con el resto de los miembros. Para ello, se trata de entender qué cosas ofrecen a cada persona mayores satisfacciones o cuáles son las que cada uno valora más. Estos valores suelen ser la satisfacción en el trabajo, los retos progresivos dentro de su carrera y dentro del proyecto, un sentimiento interior de autorrealización y de contribución al proyecto y al equipo, sentimientos de crecimiento profesional y personal, la compensación económica y la promoción en la escala laboral y otra clase de recompensas o reconocimientos a veces morales o psicológicos. Los motivadores varían con la edad, las diferencias culturales, la posición de partida y hasta qué punto estén resueltas las necesidades más básicas, según la célebre pirámide de Maslow.

  • La influencia. El liderazgo en proyectos TIC se muestra más a través de la influencia y el reconocimiento que a través de la autoridad y los procesos formales. La influencia se muestra liderando a través del ejemplo, haciéndose respetar en su propia área de conocimiento y experiencia (los profesionales respetan a los profesionales y desprecian a los incompetentes), usando un estilo de dirección flexible y ajustado a cada tipo de público, clarificando el proceso de toma de decisiones y el por qué de una decisión determinada y siendo cuidadoso en las formas. Es necesario apostar por la relación a largo plazo y no dejar que se deteriore por un conflicto o un desentendimiento puntual.

  • La toma de decisiones y solución de problemas. La toma de decisiones y solución de problemas en proyectos complejos no es una actividad intuitiva ni una intervención de emergencia, o hay que intentar que no sea así, lo máximo posible. Decisiones tomadas precipitadamente, ante problemas mal definidos, sin la información relevante y el análisis y consultas adecuadas, y sin la evaluación de su impacto sobre el proyecto, suelen conducir al error y minan la confianza del equipo y del cliente en el jefe de proyecto. La toma de decisiones en proyectos TIC debe obedecer a una estrategia y un plan, basado en 1) el análisis de la situación y los intereses y fuerzas de las partes, 2) la valoración y priorización de los propios intereses sobre cada tema de discusión, estableciendo unos máximos deseados y unos mínimos aceptables, 3) la búsqueda y evaluación de alternativas favorables para las dos partes y que mantengan la relación a largo plazo, 4) la preparación de un plan de implantación, su ejecución y seguimiento, 5) la evaluación posterior a la implantación.

  • Sensibilidad política y cultural. Los proyectos, especialmente los proyectos complejos y mixtos (que involucran la aplicación de las TIC al negocio), representan alteraciones del statu quo, de los equilibrios de poder y de las costumbres y formas de hacer. Como hemos señalado al referirnos a la gestión de interesados, el líder de proyecto no puede ignorar esta realidad y debe desplegar técnicas y habilidades para diagnosticar e intervenir adecuadamente sobre las situaciones que afectarán al resultado del proyecto. Con relación a los aspectos culturales puede decirse otro tanto. Las culturas y estilos de trabajo del cliente, los interesados y los miembros del equipo (y contratistas) pueden tener una fuerte influencia en la capacidad del proyecto para cumplir sus objetivos. La "cultura" quiere decir un conocimiento y comportamiento compartido (unas "normas" o reglas de actuación) sobre cómo se hace el trabajo, qué se considera aceptable y qué no, y quién es formal o informalmente influyente para hacer que el trabajo se haga. La cultura afecta también a las normas de comunicación interna y otros "activos" de la organización en los que el proyecto debe convivir

7.5.La gestión de los recursos humanos del proyecto

Aparte del entrenamiento y el despliegue de un conjunto de habilidades de gestión de las personas, en el proyecto se produce un conjunto de procesos formales de gestión de recursos humanos, en los que conviven políticas y procesos propios del proyecto y otros que son de la organización de la que proviene el equipo (el mismo cliente, si es un proyecto realizado con recursos propios, o un tercero, si es un proyecto contratado al exterior). Por tanto, las capacidades del líder de proyecto de influir sobre esos procesos y políticas están en cierta medida limitadas.
Sin embargo, el jefe de proyecto puede actuar directamente o influir activamente sobre algunos de estos procesos: 1) la preparación del plan de recursos humanos en su conjunto, 2) la organización del proyecto y la asignación de roles y responsabilidades; 3) la negociación e influencia para la asignación de los perfiles adecuados en el momento adecuado, 4) la fijación de objetivos y necesidades de desarrollo individual dentro del proyecto, 5) el feedback y reconocimiento en el día a día, 6) las evaluaciones del desempeño, 7) el cumplimiento de las políticas de reconocimiento y recompensa.