Organización y gestión de interesados del proyecto

  • Pere Mariné Jové

    Pere Mariné Jové

    Ingeniero superior en Informática (UPC), magíster en Gestión pública (UAB), DEA en Sociedad del conocimiento y de la información (UOC) y PMP del Project Management Institut. Consultor de estrategias tecnológicas de negocio y de metodologías de dirección de proyectos. Ha trabajado como director de SI y director de proyectos en diversas organizaciones, públicas y privadas, grandes y pequeñas. Ha sido consultor y formador de metodologías de dirección de proyectos, externalización y calidad, como colaborador externo, desde el 2001 en la UOC en las asignaturas de GP/MGPI y GOPI de las ingenierías de Informàtica y también de Gestión de proyectos en el máster TIC, y también en la UAB.

  • José Ramón Rodríguez

    José Ramón Rodríguez

    Profesor de Dirección de las TIC de los Estudios de Informática, Multimedia y Telecomunicaciones. Es también consultor independiente. Licenciado en Filosofía y Letras, PDG de IESE, Cuerpo Técnico de la Seguridad Social y diplomado por la Harvard Business School. Tiene más de diez años de experiencia en la gestión de servicios públicos y más de veinte como consultor y directivo de compañías de consultoría y de servicios de sistemas de información. Ha sido gerente adjunto y CIO del Ayuntamiento de Barcelona, consejero delegado del Instituto Municipal de Informática, y socio de Ernst & Young (actualmente CapGemini) y PricewaterhouseCoopers (actualmente IBM Business Consulting).

PID_00201165
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya), no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

Introducción

A lo largo de la asignatura 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 (en nuestro caso, toda la clase de proyectos de inteligencia de negocio) 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.
Otro aspecto a destacar 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, aún más en proyectos BI, que son, como dijimos, por naturaleza “proyectos mestizos”, a medio camino entre los temas técnicos y los temas de negocio.
Como hemos comentado repetidamente, 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, con 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.
Dado que un proyecto es un esfuerzo de personas, la gestión de las personas será lo que conduzca al fracaso o al éxito del proyecto y la gestión de personas incluye el propio equipo de trabajo y la relación con el cliente, los usuarios y los contratistas. Por este motivo, nos ha parecido adecuado dedicar un módulo 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 cómo 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, diversos elementos:

  • 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.

  • 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.

  • 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, recordad que llamamos gestión del cambio (no nos referimos a 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 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), y también un proceso activo y sistemático de manejar el cambio para que las cosas que tienen que pasar, pasen.

Objetivos

Al término del estudio de este módulo, deberéis haber alcanzado los siguientes objetivos:

  1. 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.

  2. 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.

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

1.Aspectos generales de la organización de los proyectos TIC

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).
En el caso de proyectos BI, según hemos ido viendo, el número y tipo de roles es frecuentemente más amplio y complejo.

1.1.Roles principales en el proyecto

Dentro del proyecto hay tres roles clave:

  • 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. Según hemos comentado, en los proyectos BI recomendamos que el sponsor sea un miembro del equipo de Dirección de la compañía.

  • El jefe de proyecto tiene la responsabilidad de supervisar y controlar la ejecución del proyecto para asegurar que cumpla los objetivos y las previsiones de 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.

  • 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 estos, con el gerente.

    Actualmente, los miembros del equipo suelen pertenecer a la organización del cliente (los departamentos de negocio afectados por el proyecto), 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, normalmente hace 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 y 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 mismo, 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).

1.2.El director o jefe de proyecto

El jefe de proyecto es el responsable del día a día del proyecto. 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 los objetivos en tiempo y costes y con 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 comporta:

  • Hacer que las cosas se hagan con ayuda de 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 algunas cualidades especiales o carisma y además tiene competencias técnicas que el equipo reconoce.
Un buen jefe de proyecto ha de poder, entre otras cosas:

  • 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.

  • Proponer y ejecutar acciones y decisiones para, cuando sea necesario, corregir situaciones de forma flexible y efectiva que repercutan en el éxito del trabajo y de la gente.

  • Comunicar sus decisiones de forma adecuada en el contenido, en la forma y en el tiempo, para obtener la comprensión y el apoyo de las partes involucradas.

Este equilibrio entre 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), ni 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). Un buen jefe de proyecto es un buen gestor de personas, un buen coach y un buen comunicador.
Quién debe 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 mismo. 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í. Frecuentemente, en proyectos BI, el patrocinador prefiere escoger una persona de su organización o departamento, que conoce bien el negocio, los datos 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, que veremos más adelante, 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. A él será a quien le corresponderá 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 sido 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)

1.3.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 deben tomar decisiones. Este comité, normalmente, está presidido por el sponsor o patrocinador y asume las siguientes funciones:

  • Aprobar el plan de hitos y la 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.

1.4.Otros roles que afectan directamente al proyecto

Además de los anteriores, hay al menos otros tres roles demasiado cercanos al proyecto como para dejarlos ahora de lado:

  • 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.

  • 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.

  • 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.

Otro aspecto a tener en cuenta es que cada vez es más habitual encontrar organizaciones de proyecto en las que se produce una cierta relación especular entre la estructura del cliente y la estructura del proveedor o proveedores. 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.
A lo largo de todo este apartado, defenderemos estructuras sencillas e integradas entre el personal del cliente y del proveedor y con unidad de mando, pero somos conscientes de que eso no siempre es posible ni práctico.

1.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 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 especifica cuál es 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 que, en ocasiones, se confunden:

  • Rol. 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.

  • Autoridad. Derechos formalmente asignados a alguien para aplicar recursos, tomar decisiones y firmar o rechazar aprobaciones. La situación perfecta es aunar responsabilidad y autoridad: responsabilidad sin autoridad suele ser una mala combinación.

  • Responsabilidad. Espacio, á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 puede no ser accountable: no todos deben rendir cuentas, normalmente, lo hará un superior.

  • Competencia. 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 muestran 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 presenta sólo cuatro roles:

  • Responsible (R): el encargado de realizar o ejecutar el trabajo.

  • Accountable (A): el responsable último, el supervisor, el que tiene la autoridad, toma decisiones o tiene que dar cuentas sobre el trabajo realizado.

  • Consult (C): alguien que debe ser consultado y apoyar el trabajo.

  • Inform (I): alguien que debe ser informado.

En la siguiente figura mostramos un ejemplo de matriz RACI para un trabajo típico de desarrollo de un sistema de información:
Figura 1. Ejemplo de Matriz RACI
Figura 1. Ejemplo de Matriz RACI
La matriz de roles y responsabilidades, cualquiera que sea el formato elegido, 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.

2.El cliente y la gestión de interesados

Los interesados (stakeholders) en un proyecto son todas las personas y organizaciones que se verán afectadas por el desarrollo del proyecto, sea directamente, porque participan en él 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, cualificar su influencia dentro de la organización y establecer estrategias para facilitar la participación de aquellos que son necesarios para el éxito y la aceptación del proyecto y los productos o para minimizar las barreras de adopción por parte 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 sus preocupaciones y resolver incidencias (issues), tales como:

  • Gestionar 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 mismo.

  • Atender sus preocupaciones (concerns), que todavía no se han convertido en incidencias (issues), para anticipar problemas futuros. Estas preocupaciones necesitan ser puestas sobre 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.

  • 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 como parte del proyecto al que deberán aportar conocimiento y recursos. Suele tratarse de 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 (legacy) 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.

Fuente: PMBOK (2008), 4ª ed., pág. 261.
Genéricamente, se pueden considerar interesados los siguientes grupos:
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.
En el módulo “Desarrollo de un proyecto de inteligencia de negocio”, cuya revisión recomendamos ahora, hemos indicado algunos procesos y técnicas de identificación, registro y cualificación de interesados propios de la etapa de Iniciación. Este proceso puede verse gráficamente en la siguiente figura:
Figura 2. Proceso de gestión de interesados
Fuente: Rodríguez, García, Lamarca (2007).
Fuente: Rodríguez, García, Lamarca (2007).
Lo que más nos interesa en este apartado es establecer las políticas de gestión y proporcionaros algunos consejos prácticos.
Los aspectos políticos de cualquier proyecto
En primer lugar, el estudiante y el 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 y que también, por lo tanto, hace política. No es una estatua de hielo a salvo de sus intereses y emociones, y todo ello influye en sus relaciones, en su interacción con las personas e, inevitablemente, en sus decisiones. Es bueno, por lo tanto, aprender a reconocerlos y a mostrarlos honradamente, si se pretende 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 durante y después de un proyecto; es decir, las decisiones de asignación de recursos, el reparto de responsabilidades y los cambios en los procesos y la organización del negocio y en las formas de trabajar.

  • 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.

  • 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.

  • 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.

  • 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 en mayor medida a satisfacer sus propios intereses que los de la dirección o los de la empresa como un todo.

  • 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.

Según vimos en el módulo “Características de los proyectos de inteligencia de negocio”, muchos proyectos BI son especialmente “políticos”. Un proyecto BI, 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. 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.

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

El primer paso para poder gestionar adecuadamente la política en un proyecto, insistimos, es reconocer su existencia; es decir, 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 3. Ejemplo de mapa de interesados
Figura 3. Ejemplo de mapa de interesados
Lo segundo es ver que cada grupo requiere una estrategia diferente y que no son tantos. No parece que se deba dedicar mucho tiempo a los neutros ni a aquellos cuya colaboración no es indispensable (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 están en aquellos cuyo impacto e influencia es alto (e incluso medio), cuya cooperación es necesaria y cuya posición es de entusiasmo o de oposición. Esos son el objetivo y a los que se debe dedicar tiempo y esfuerzo.
Un entusiasta, cuya cooperación es necesaria y que tiene un impacto alto, puede ser un campeón (champion) interno del proyecto, alguien que hará de propagandista convencerá a los neutrales y debilitará a los opositores. Se necesitan 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 dar a entender a cada interesado clave algo muy sencillo: “¿qué gano yo con esto (1) ?”. 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 postimplantación, habrá mucho ganado. También suele ser práctico dejar de invertir o mantener los sistemas heredados y mostrar sus deficiencias.
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 esta 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 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: se debe 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:

  • Que el sistema se use por 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 superautopistas de la información, infrautilizadas durante más de una década, o el de la mayoría de las aplicaciones transacciones 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, especialmente en proyectos BI que necesitan sostenerse en el tiempo e incorporar continuamente nuevos datos y usuarios.

  • Una implementación exitosa de productos o servicios TIC requiere inevitablemente tanto modificaciones 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. Hemos recomendado metodologías “ágiles” para proyectos de BI, en las cuales el usuario final participa en la creación del producto y ve continuamente prototipos.

  • 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 y, en el caso de BI, en cómo se toman las decisiones. Es muy difícil evaluar el éxito de una implantación al acabar el proyecto y con la aceptación de los entregables.

En proyectos BI es especialmente importante analizar e intervenir sobre el proceso de adopción y difusión de la solución. A través de técnicas adecuadas, es posible analizar la situación de los usuarios potenciales con relación al proceso de adopción y actuar sobre cada grupo mediante una mezcla de técnicas, además de las de autoridad, que proceden fundamentalmente del mundo del marketing y la comunicación empresarial.
En el apartado siguiente, mostramos los aspectos peculiares de la organización de proyectos de inteligencia de negocio.

2.2.Aspectos especiales de la organización de proyectos de inteligencia de negocio

En el mòdulo “Características de los proyectos de inteligencia de negocio” hemos presentado la complejidad y características especiales de los proyectos de business intelligence y en el módulo “Ejecución de un proyecto de inteligencia de negocio” hemos propuesto una metodología específica para la ejecución de esta clase de proyectos. Estas características afectan también al modelo organizativo del proyecto.
La complejidad de los proyectos de inteligencia de negocio
Como venimos repitiendo a largo del material, los proyectos BI son de los más complejos que se dan en el mundo de las TIC y de los negocios:

  • Los analistas hablan de hasta un 70% u 80% de proyectos fracasados (Gartner).

  • Curto presenta hasta 90 componentes y productos diferentes.

  • Loss y Atre hablan de hasta 30 profesiones y roles distintos, hasta 50 tipos de proyectos diferentes y hasta 900 tipos de actividades con decenas de dependencias en la hoja de ruta de un proyecto grande.

  • Entre los proyectos TIC, los de inteligencia de negocio son los únicos en que el amo del proyecto sólo puede ser el negocio (nunca el departamento de IT). Esta es generalmente gente con altas expectativas, poca consciencia y conocimiento de la complejidad, mucha impaciencia y poca dedicación

  • Entre los proyectos empresariales, los de Los proyectos inteligencia de negocio son los más definitivamente integradores y transversales; es decir, cruzan toda la organización, sus datos y sus aplicaciones, y además desafían el embrollo de los desarrollos departamentales y la propiedad de la información.

  • Los proyectos de inteligencia de negocio son extraordinariamente tecnológicos, complejos, detallados y profesionales para el departamento de IT o para sus partners: arquitecturas funcionales y técnicas, requerimientos técnicos y del negocio, análisis de los datos y sus fuentes, diseño y construcción de metadatos, procesos de ETL y cubos OLAP, minería de datos, conocimiento de las aplicaciones, los gestores de bases de datos y las capas de integración, herramientas y habilidades de visualización y navegación, políticas de seguridad, gestión de la infraestructura y optimización de los rendimientos...

  • Los proyectos de inteligencia de negocio requieren un tipo de proyecto y diálogo con el usuario (¡y vaya usuario!) muy diferente, basado en prototipos, en prueba y error, y en el aprendizaje por el uso. El resultado, probablemente, es menos importante que el desarrollo de capacidades internas y la credibilidad y éxitos para seguir trabajando. Son, o deberían ser, proyectos “ágiles”, aunque no precisamente rápidos. Y además no se acaban, o no se deberían acabar, nunca: la diferencia entre el “modo proyecto” y el “modo operación” se difumina en nuevas releases de más datos para más usuarios más exigentes.

  • Las empresas necesitan desarrollar capacidades de liderazgo directivo, trabajo en equipo, talento analítico y una cultura de toma de decisiones basadas en los datos (a data-driven mindset) que desafía los silos departamentales y jerárquicos y las decisiones basadas en la intuición o la opinión.

Las diferencias son también cualitativas:
Como ya hemos comentado, un proyecto BI requiere un conjunto complementario de capacidades para desarrollar las diferentes actividades que derivan de sus distintas partes o subproyectos y, sin embargo, todas estar partes requieren de una coordinación en un proyecto común, lo que hemos llamado, de acuerdo con el PMBOK, la gestión integral del proyecto.
Para asegurar esta integración y, a la vez, diversidad, Loss y Atre (2003) recomiendan la existencia de dos clases de equipos:

  • El equipo central (core team).

  • El equipo extendido.

El equipo central es también el equipo permanente y con una dedicación a tiempo completo, mientras que el equipo extendido actúa en algunas fases y subproyectos, y puede tener una dedicación completa o parcial.
Es importante señalar que, de acuerdo con la metodología propuesta, en cada fase o etapa del proyecto de ejecución se involucran perfiles diferentes con roles diferentes. Recordemos las etapas tal como las presentábamos en el módulo “Desarrollo de un proyecto de inteligencia de negocio”:
codi_m4_020.gif
2.2.1.El equipo central
El equipo cental suele ser un equipo pequeño, flexible y autoorganizado, que prácticamente asume de forma colegiada la dirección del proyecto. Se compone de:

  • Una unidad central o de coordinación de las diferentes líneas de trabajo (la ETL, el repositorio de metadatos y las aplicaciones), llamada equipo permanente.

  • Unidades satélite en cada fase del trabajo, en las que su participación debe ser especialmente intensiva, llamada equipo permanente en cada fase.

Normalmente, el equipo permanente central está compuesto por:

  • Un jefe de proyecto.

  • Un representante del negocio.

  • Un analista funcional del departamento de IT.

  • Una persona técnica del deparatamento de IT.

Se espera que los miembros del equipo permanente central tengan dedicación plena mienras dure el proyecto. Es especialmente crítica la posición del representante del negocio (o líder funcional), que debe tener una delegación de autoridad y línea directa con el que hemos llamado cliente o espónsor del proyecto, especialmente si se trata de un proyecto transversal que afecta diferentes departamentos, unidades de negocio o procesos.
El equipo satélite, asignado a cada fase del trabajo, también debe estar dedicado al 100% durante dicha fase. Los roles típicos de este equipo satélite son los siguientes:

  • Jefe de proyecto (responsable del subproyecto o track)

  • Líder funcional (lo mismo, desde el punto de vista del negocio)

  • Desarrollador y/o parametrizador de aplicaciones

  • Arquitecto de la infraestructura de BI

  • Administrador de datos (de origen)

  • Experto en minería de datos

  • Analista de la calidad de datos

  • Administrador de las bases de datos (del BI)

  • Desarrollador y/o parametrizador de ETL

  • Administrador del respositorio de metadatos

  • Experto en los datos y procesos del área de negocio

Es importante señalar que cuando hablamos de “roles” no queremos decir necesariamente personas. Una persona puede hacer varios roles, según el tipo de proyecto y la capacidad de la compañía o de sus partners, si el proyecto se está realizando con ayuda externa. Y al revés, un determinado rol (por ejemplo, desarrolladores de aplicaciones o representantes de partes del negocio) puede estar desempeñado por varias personas.
2.2.2.El equipo extendido
La diferencia entre el equipo central y el equipo extendido radica en que los miembros de este último no están dedicados completamente al proyecto, no es su objetivo principal; participan en el proyecto, según la matriz de responsabilidades (RACI), mayoritariamente en funciones consultivas o de información y simplemente deben programar su dedicación y/o disponibilidad cuando se les requiere.
El rol más importante en el equipo extendido es el de espónsor del proyecto (líder de negocio). Normalmente será un miembro del equipo de dirección de la compañía que, por un lado, hace de “cliente” y, por lo tanto, debe asegurar el cumplimiento de los objetivos y aceptar los productos y, por otro lado, debe asignar los recursos y remover las barreras organizativas que puedan impedir el progreso del proyecto.
Los roles más habituales dentro del equipo extendido son los siguientes:

  • Espónsor del proyecto

  • Desarrolladores y/o parametrizadores de aplicaciones

  • Desarrolladores y/o parametrizadores de ETL

  • Desarrolladores y/o parametrizadores del respositorio de metadatos

  • Desarrolladors y/o parametrizadores del entorno de acceso y navegación

  • Diseñadores

  • Soporte al usuario

  • Control de calidad de datos

  • Control de calidad (IT)

  • Responsable de arquitectura de datos, procesos y aplicaciones (IT)

  • Responsable de redes (comunicaciones)

  • Responsable de seguridad (IT)

  • Responsable de operaciones y explotación

  • “Propietarios” de datos

  • Analistas de datos

  • Otros usuarios

  • Otro staff de IT

2.2.3.Organos colegiados: el comité de dirección
Como ya hemos comentado, en el método propuesto y en su estructura de organización asociada, la organización es muy compleja, pero a la vez muy flexible, colegiada y orientada a la acción.
En proyectos transversales, en los que tienen una elevada contribución los representantes del “negocio” (departamentos funcionales, unidades de negocio autónomas...), y que a su vez son dinámicos y sujetos a la entrega ininterrumpida de releases, es inevitable que aparezcan cambios, conflictos, nuevas peticiones e implicaciones técnicas, sobre las que alguien debe de resolver. Eso aconseja la creación de un “órgano de arbitraje” (o incluso dos, siendo uno separado dentro del departamento de la propia IT).
Este órgano se constituye en el comité de dirección del proyecto, que en organizaciones más maduras y con un BI en proceso de desarrollo y ampliación puede ser un comité permanente de usuarios.
Cada comité debe adaptarse a la idiosincrasia del proyecto y de la compañía e, incluso, puede tomar la forma de un comité ya existente. Esta clase de comités suele tener la siguiente composición:

  • El espónsor del proyecto, normalmente un miembro del comité de dirección de la compañía

  • El máximo responsable de los sistemas de información (el CIO, o el director de informática)

  • El director de operaciones (COO), si existe; o sea, la máxima autoridad de la gestión del día de la empresa por debajo del director general o primer ejecutivo

  • El director financiero (CFO), que es normalmente el responsable del reporting al comité de diección y al consejo de administración

  • Algunos responsables o representantes de negocio

  • Algunos responsables de departamentos o procesos de IT

2.2.4.El centro de competencias
En los últimos años, en muchas organizaciones, sobre todo en un momento inicial de la explotación de sus sistemas de BI, se han creado “centros” (reales) o “redes” (virtuales) de expertos que conocen los procesos de explotación y análisis del BI y son capaces de realizar trabajos de diferente complejidad técnica:

  • Construir o modificar cubos OLAP

  • Lanzar interrogaciones (queries)

  • Preparar informes (reports) estáticos o dinámicos

  • Construir cuadros de mando

Los miembros de estos centros o redes suelen ser analistas de datos o usuarios avanzados, que frecuentemente también interactúan o intermedian entre los usuarios finales, la organización corporativa del BI y el departamento de IT. También hacen de champions o valedores del sistema dentro de la organización y pueden actuar como formadores de formadores y de usuarios finales.

3.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 deben desarrollar todos lo miembros del equipo, especialmente el jefe de proyecto, 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 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:

  • 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

3.1.El liderazgo

Puede definirse 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 se forma el equipo) 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 (hay personas que no están dotadas y personas que 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.

3.2.Hacer equipo, motivar e influir

El liderazgo, la capacidad de construir y desarrollar un equipo son habilidades que van muy unidas.
Hacer equipo 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 buen liderazgo y hacer equipo se llama buen trabajo en equipo”.
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 personas del cliente, de los subcontratistas y, eventualmente, de otras partes interesadas, y también 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, lo que incluye, principalmente:

  • Establecer reglas claras de comportamiento (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.

  • Resolver los problemas y conflictos que surjan en el seno del equipo.

  • 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.

  • 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.

  • 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 el 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.

  • Reconocimiento y recompensas. El plan de recursos humanos y las reglas de la compañía deben permitir que el líder de proyecto establezca objetivos conseguibles, 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.

    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é ofrece a cada persona mayores satisfacciones o qué es lo 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 retos 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 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 conflictos 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 resentimientos. 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.
La escala de Tuckman. 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 (la escala de Tuckman). 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. Estas cinco fases son las siguientes:

  • 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.

  • 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.

  • Normalización (norming). En esta fase, los miembros del equipo se acostumbran a trabajar juntos y ajustan sus hábitos y comportamientos. Comienza a haber confianza entre sus miembros.

  • 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.

  • 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.

3.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 (a veces, su 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. Lo que no es conveniente es cambiar dichas reglas 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 respecto a 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), establezca 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 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 la solución de problemas en proyectos complejos no es una actividad intuitiva ni una intervención de emergencia; cuando menos, hay que intentar que no lo sea.
Las 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 4. Secuencia de toma de decisiones en un proyecto
Fuente: Rodríguez, García, Lamarca (2007)
Fuente: Rodríguez, García, Lamarca (2007)
Tomar decisiones tiene una parte de proceso estructurado (al cual nos acabamos de referir), 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 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.

  • Todas las decisiones suponen riesgo 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.

  • 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.

Fuente: Rodríguez, García, Lamarca (2007).

3.4.Sensibilidad cultural y política

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, debe 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 como son los de BI (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 indicado repetidamente, el éxito de los proyectos BI se produce especialmente en culturas empresariales “orientadas a los datos”, y/o en la capacidad de generar liderazgos y proyectos que desarrollen estas culturas.
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 a otros activos de la organización con los que el proyecto debe convivir. Los más importantes son los siguientes:

  • La visión y valores, lo que podríamos llamar la filosofía de la empresa: cuál es su aspiración delante de 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, etc.

  • 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 a 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 que 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.

3.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 cubre 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, con los interesados, con 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.
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 en conflictología llaman “estrategia 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 es bueno disponer de una buena estrategia y seguir un proceso ordenado.
Figura 5. Secuencia de una buena negociación
Figura 5. Secuencia de una buena negociación

Resumen

Un proyecto es el esfuerzo y la gestión de las personas que lo conducen hacia el 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, diversos elementos:

  • 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.

  • 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.

  • 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 (diferente a 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 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 gestión del cambio para que las cosas que tienen que pasar, pasen.
Lo que llamamos el lado humano de la gestión de proyectos incluye diversos 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. Llamamos a estos aspectos 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, en las operaciones o, sobre todo, en proyectos BI, en la manera como las empresas y sus directivos toman las decisiones.
En los proyectos de inteligencia de negocio interviene un gran número de roles y responsabilidades, muchos perfiles y especialidades, de forma permanente o temporal, por lo que deben dotarse de una organización muy flexible y orientada a la acción. Hemos sugerido la existencia de un equipo central y permanente, formado por gente dedicada al proyecto a tiempo completo y de un equipo extendido, dedicado parcialmente y/o disponible a petición. El rol del espónsor de negocio y una gran involucración de los responsables de negocio es aún más importante que en otro tipo de proyectos TIC: los proyectos de BI son esencialmente proyectos de negocio, soportados por tecnologías muy sofisticadas.