gestión de proyectos

El lado humanode la gestin deproyectos

Jos Ramn Rodrguez

PID_00215844

FUOC PID_00215844 El lado humano de la gestin de proyectos

Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico,qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escritade los titulares del copyright.

FUOC PID_00215844 El lado humano de la gestin de proyectos

ndice

Introduccin............................................................................................... 5

Objetivos....................................................................................................... 7

1. El "lado humano" de la gestin de proyectos............................. 91.1. El "lado humano" en PMBOK ..................................................... 12

2. La organizacin del proyecto......................................................... 142.1. Roles que afectan directamente al proyecto ............................... 142.2. Roles principales en el proyecto ................................................. 152.3. El director o jefe de proyecto ..................................................... 162.4. El Comit de Direccin ............................................................... 182.5. La matriz de roles y responsabilidades ....................................... 19

3. Gestin de interesados...................................................................... 233.1. Los aspectos polticos de cualquier proyecto .............................. 243.2. Cmo se gestiona la poltica en el proyecto ............................... 26

4. La comunicacin................................................................................ 304.1. El proceso de comunicacin ....................................................... 314.2. Algunas reglas bsicas ................................................................. 34

5. Habilidades interpersonales............................................................ 365.1. El liderazgo .................................................................................. 365.2. Hacer equipo, motivar e influir .................................................. 385.3. La toma de decisiones y resolucin de problemas ...................... 425.4. Sensibilidad poltica y cultural ................................................... 455.5. La negociacin ............................................................................ 47

6. La gestin y desarrollo de las personas....................................... 516.1. Los procesos de gestin de recursos humanos en el proyecto .... 51

7. Resumen................................................................................................ 547.1. Organizacin del proyecto .......................................................... 557.2. Gestin de interesados ................................................................ 567.3. Comunicacin ............................................................................. 567.4. Habilidades interpersonales ........................................................ 577.5. La gestin de los recursos humanos del proyecto ...................... 59

FUOC PID_00215844 5 El lado humano de la gestin de proyectos

Introduccin

A lo largo de este material hemos ido presentado una disciplina nueva paramuchos, la gestin de proyectos, poniendo un empeo especial en marcar lasdistancias con las metodologas de construccin y despliegue de cada productoo servicio TIC especfico que, segn hemos presentado, se integran dentro dela etapa de ejecucin. El proyecto empieza antes y acaba despus y comprendemuchas ms acciones.

El segundo mensaje que deseamos que el alumno retenga es que los proyectosTIC tienen que ver, normalmente, con oportunidades y problemas de negocioque el cliente desea resolver y no con una coleccin de entregables ms omenos bien construidos o unos procesos de gestin ms o menos rigurosos. Elproyecto sirve si resuelve esos problemas.

Segn vimos desde el inicio, la causa de la mayor parte de los fracasos en losproyectos TIC no se debe a causas tecnolgicas, sino a problemas relacionadoscon la gestin del alcance (y, por tanto, de la comprensin de las necesidadesde los clientes), problemas de comunicacin y gestin de las expectativas delos usuarios y problemas relacionados con lo que el cliente tiene que haceren su organizacin (liderar y comprometerse, asignar recursos, cambiar losprocesos o la organizacin) y frecuentemente no hace.

Porque un proyecto es un esfuerzo de personas y es el manejo de las personaslo que lo conduce o no, al final del da, al fracaso o al xito. As es dentro delequipo de trabajo y en la relacin con el cliente, los usuarios y los contratistas.

De manera que nos ha parecido adecuado dedicar un ltimo captulo a lo queuno de los autores clsicos de esta disciplina (Pinto y Millet, 1999) llam "ellado humano" de la gestin de proyectos, y recopilar y desarrollar aqu algunosde los temas que hemos tratado ms ligeramente a lo largo del resto de losmdulos (como son los procesos de organizacin del trabajo, comunicaciny gestin de expectativas) e introducir otros nuevos, presentando el conjuntode una forma un poco ms sistemtica de como se acostumbra a hacer en losmanuales.

Creemos que una aproximacin a la gestin de personas dentro de la gestinde proyectos no debe ser un enunciado de buenos propsitos, sino una disci-plina en s misma en la que deben alinearse, para tener xito, varias clases deelementos:


1) El diseo de la organizacin del proyecto, es decir, la clarificacin de losroles y responsabilidades de sus miembros, en particular, en los niveles dedireccin, por parte del cliente y del equipo.

2) La gestin de los interesados (stakeholders), es decir, la identificacin inte-ligente del impacto e influencia del proyecto sobre las diferentes partes de laorganizacin, su predisposicin a la adopcin y las estrategias a desplegar.

3) Los procesos de comunicacin, formal e informal, con relacin a las partesinteresadas y dentro del equipo, es decir, la gestin de los mensajes, medios,formatos, estilos, portavoces, periodicidad, etc.

4) La gestin y desarrollo de las personas individuales que forman el equipo ydel equipo en su conjunto y, por lo tanto, las polticas y procesos de recluta-miento, asignacin, desarrollo, formacin y recompensa.

5) Las habilidades interpersonales que deben desarrollar los miembros delequipo y, sobre todo, el director o jefe de proyecto, en particular las de comu-nicacin, toma de decisiones, liderazgo, motivacin, trabajo en equipo, nego-ciacin y resolucin de conflictos.

Finalmente, llamamos gestin del cambio (y no, ya lo dijimos, la gestin delos cambios en el alcance o en otras dimensiones del proyecto) a todas aquellascosas que deben producirse en el cliente para que el proyecto tenga xito. Estoincluye, asimismo, una comprensin clara de la misin del trabajo desde unpunto de vista del negocio, el liderazgo y compromiso de la direccin (mos-trado en las decisiones difciles y la asignacin de recursos) y acciones sobrela organizacin (roles y responsabilidades), los procesos de gestin y, muchasveces, los recursos humanos (en cantidad y calidad). E incluye un proceso ac-tivo y sistemtico de manejar el cambio para que las cosas que tienen que pa-sar, pasen.

Gestin del cambio

La gestin del cambio merecera un captulo separado (y como sealamos en su momen-to, un rea de conocimiento diferenciada dentro de PMBOK y otros estndares de la pro-fesin), ya que incluye una aproximacin, procesos y tecnologas muy variadas y com-plejas en un mbito disciplinario muy nuevo y poco codificado. Por nuestra parte inclui-mos en este captulo algunos temas que refuerzan la gestin del cambio dentro del pro-yecto, pero sin darle de momento un tratamiento diferenciado y desarrollarlo a fondo.


Objetivos

Al trmino del estudio de este mdulo, los estudiantes deberis conocer y estaren condiciones de aplicar vuestros conocimientos en las siguientes materias:

1. En qu consiste el "lado humano" de la gestin de proyectos y cules sonsus diferentes componentes y las relaciones entre ellos.

2. Comprender el diseo de la estructura de organizacin de un proyecto, losdiferentes roles y responsabilidades, en particular el rol de jefe o directorde proyecto y algunas de las herramientas ms utilizadas.

3. Comprender de una forma integral e integrada los componentes de la ges-tin de interesados, tanto en el diagnstico como en la intervencin parael xito del proyecto.

4. Comprender los componentes bsicos de la comunicacin dentro del pro-yecto y sus principales procesos de gestin.

5. Comprender los principales componentes y procesos de gestin y desarro-llo de las personas dentro del equipo y de construccin y desarrollo delequipo en su conjunto.

6. Comprender las necesidades de desarrollo de las habilidades interpersona-les imprescindibles para la gestin de las personas y sus relaciones dentrodel proyecto.


1. El "lado humano" de la gestin de proyectos

"Estamos convencidos (y esta visin est soportada por evidencias sus-tanciales) de que la mayor parte de los fracasos en la implantacin desistemas de informacin se debe a fracasos en la gestin de los proyec-tos. Es decir, la mayora de las razones por las cuales estos sistemas nose implantan con xito no tiene que ver con causas puramente tcni-cas, sino con una gestin eficiente del proyecto. La gestin del proyec-to quiere decir comprender el alcance y el calendario, establecer obje-tivos, descomponer el trabajo, gestionar los recursos, manejar el ladohumano de la implantacin y entender cmo superar las barreras deaceptacin y uso de los sistemas por parte de su pblico objetivo" (Pintoy Millet,1999).

Desde que Pinto y Millet, autores del manual de referencia en la materia, es-cribieron esta afirmacin, pocas cosas han cambiado, al menos de acuerdocon las evidencias cientficas, los anlisis que elabora la consultora The Stan-dish Group sobre implantacin de proyectos TIC en todo el mundo y la prc-tica profesional de clientes y empresas de servicios. Sus afirmaciones, pensa-das para proyectos de implantacin de sistemas de informacin, son aplica-bles a proyectos multimedia, donde los usuarios son internos y externos a laorganizacin (los problemas de adopcin y uso de la tecnologa, an ms siincluyen transaccionalidad y compra, pueden ser an ms dramticos) y, conmatices, a muchos proyectos de telecomunicaciones, que no sean puramentede despliegue de infraestructura.

Como hemos venido presentando, los problemas relacionados con la implan-tacin que tienen que ver con las personas no se producen slo en el momen-to de la adopcin de la tecnologa, sino a lo largo de todo el proyecto, en lacomprensin compartida de los objetivos de negocio, en la definicin de lasnecesidades del proyecto, de los entregables, de los requisitos funcionales, delas exigencias de participacin de los usuarios, de la toma de decisiones de ladireccin, de la gestin de los cambios, de la integracin con los sistemas he-redados, de la realizacin de pruebas y de la transformacin de la organizaciny procesos del cliente, por citar slo algunos de los ms crticos.

Rodrguez, Garca y Lamarca citan muchas razones de fracaso de los proyectosque tienen que ver con las personas (tabla 1).

Bibliografa

J.Pinto;I.Millet (1999). Suc-cessful information system im-plementation: the human side(2. ed.). Pennsylvania: PMI.


Tabla 1

Razones de fracaso de un proyecto relacionadas con las personas

Los miembros del equipo no tienen la formacin adecuada. Falta de supervisin. Falta de personal. Conflictos internos dentro del equipo. Conflictos por asignacin a ms 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 involucracin de los equipos del cliente. No aceptacin del proyecto por personas clave del cliente. Bajo rendimiento de personas clave del equipo. Diferente visin de los objetivos entre los miembros. El cliente no asigna recursos o no estn cualificados. Problemas con los subcontratistas

Fuente: Rodrguez, Garca, Lamarca (2007)

Para estructurar este captulo, consideraremos los componentes del "lado hu-mano" de la gestin de proyectos en cinco grupos (figura 1).

Figura 1. Componentes del ''lado humano'' de la gestin de proyectos

1) El diseo de la organizacin del proyecto, es decir, la clarificacin de losroles y responsabilidades de sus miembros, en particular en los niveles de di-reccin, por parte del cliente y del equipo.

2) La gestindelosinteresados (stakeholders), es decir, la identificacin inte-ligente del impacto e influencia del proyecto sobre las diferentes partes de laorganizacin, su predisposicin a la adopcin y las estrategias a desplegar.

3) Los procesos de comunicacin, formal e informal, con relacin a las partesinteresadas y dentro del equipo, es decir, la gestin de los mensajes, medios,formatos, estilos, portavoces, periodicidad, etc.


4) La gestinydesarrollodelaspersonas individuales que forman el equipoy del equipo en su conjunto y, por lo tanto, las polticas y procesos de reclu-tamiento, asignacin, desarrollo, formacin y recompensa.

5) Las habilidadesinterpersonales que deben desarrollar los miembros delequipo y, sobre todo, el director o jefe de proyecto, en particular las de comu-nicacin, toma de decisiones, liderazgo, motivacin, trabajo en equipo, nego-ciacin y resolucin de conflictos.

Todos estos componentes deben estar alineados entre s (es decir, asegurar lacoherencia entre unos y otros) y con el conjunto del proyecto.

Es importante sealar que cuando hablamos del "lado humano" no nos esta-mos refiriendo a componentes ms o menos emocionales o psicolgicos o, almenos, no slo a ellos. Como veremos a continuacin, el lado humano inclu-ye dos clases de elementos:

Aspectos de estructura, organizacin, y procesos (sistemas), que puedenafectar al organigrama (del proyecto y de la empresa), a los roles y respon-sabilidades, las retribuciones o la promocin de las personas, dentro delproyecto, de la empresa proveedora de los servicios o del cliente.

Aspectos de procesos de gestin del proyecto formales (como la distribu-cin de la informacin y la identificacin y gestin de interesados), habi-lidades interpersonales que pueden adquirirse y desarrollarse (las habili-dades de comunicacin, motivacin, o toma de decisiones) y aspectos queafectan a la "cultura" del proyecto o del cliente, y sobre los que cada vezexiste una mejor informacin e investigacin.

Rodrguez, Garca y Lamarca (2007) llaman al primer grupo componentes hardy al segundo grupo componentes soft, pero en ningn caso estamos hablandode psicologa ni de magia, sino de procesos, tcnicas y habilidades que puedenadquirirse con el estudio y, sobre todo, la prctica 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 atencin al pblico por Internet, se puede modificar nuestracarga de trabajo de atencin presencial o telefnica (disminuir o, curiosamente, au-mentar) y la estructura de personal, generar o contratar externamente un servicionuevo e integrarlo o no con nuestro servicio de administracin (back-office), y pedi-remos a unos y otros habilidades diferentes. El proceso global de atencin al pblicovariar y quiz estructuremos una organizacin separada para dar esta gestin exter-na (front-office), con puestos de supervisin. Puede haber horarios y turnos distintosy una estructura salarial diferente. Estos seran los componentes hard.

Es probable que los departamentos tradicionales, con razn o sin sta, vean en lanueva estructura un peligro para sus intereses. No es claro que no represente unamayor carga de trabajo sin recibir mayores recursos. Adems, pueden sentirse poster-gados o peor retribuidos que la nueva organizacin. En todo caso, debern ser forma-dos en los nuevos procesos y en el manejo de los sistemas que se implantan. Dentrode la organizacin ser importante identificar responsables de los nuevos procesos yconseguir el apoyo de mandos intermedios y de lderes de opinin entre el personal.Tambin se deber explicar el nuevo proceso y estructura a los representantes delpersonal y conseguir su no oposicin. Desde el principio hasta el final, se deber ex-plicar bien qu se est haciendo para calmar resistencias y ganar apoyos o, al menos,neutralidad. Estos seran algunos de los componentes soft.


Finalmente, y para complicar las cosas (pero es que las cosas en los proyectosson complicadas), el "lado humano" se produce, al menos, en tres organiza-ciones diferentes:

1) El proyecto, como organizacin ad hoc, un equipo nico reunido duranteun tiempo para entregar unos productos o servicios.

2) El cliente, la organizacin destinataria del producto o servicio, con sus ac-tivos de estructura, procesos, cultura, sistemas de gestin y reglas de negocio,que encarga un proyecto que "cambiar" cosas. (Este es el mbito de lo quemodernamente se llama "gestin del cambio", que no trataremos en profun-didad en este mdulo.)

3) La organizacin u organizaciones proveedoras de los servicios (o produc-tos), donde la mayora de los miembros del equipo estn sujetos a formas deorganizacin, jerarquas, carreras profesionales, sistemas de evaluacin y asig-nacin a nuevos proyectos.

1.1. El "lado humano" en PMBOK

El estndar de la profesin ha ido reconociendo paulatinamente con mayorinters e intensidad los aspectos humanos de la gestin de los proyectos, y elpropio PMI patrocina y publica cada vez ms material sobre este tema.

Aunque, como hemos comentado, su visin contina siendo limitada y pocoestructurada y sistemtica, en nuestra opinin.

PMI

El clsico de Pinto, luego au-mentado con la aportacin deMillet (1999) est publicadopor el PMI, Project Manage-ment Institute, sin ir ms lejos.


En PMBOK (2008), los aspectos de organizacin del proyecto y gestin delequipo estn incluidos en el rea de conocimiento de gestin de recursos hu-manos. La organizacin del proyecto (los roles y responsabilidades atribuidosa cada miembro) es el contenido central del proceso de desarrollo del plan derecursos humanos en la etapa de planificacin. Los aspectos de gestin de laspersonas y gestin del equipo se desarrollan durante la etapa de ejecucin.

En PMBOK (2008), los procesos de comunicacin y gestin de interesados seincluyen en el rea de conocimiento de gestin de la comunicacin. La ges-tin de interesados se realiza en la etapa de iniciacin (con la identificacin yregistro de interesados) y la en la etapa de ejecucin (cuando se hace la gestinactiva de los interesados). La comunicacin se lleva a cabo en la etapa de pla-nificacin (cuando se prepara el plan de comunicacin del proyecto), durantela ejecucin (principalmente, mediante la distribucin de la informacin) y elcontrol (la preparacin de los informes de progreso).

La ltima edicin de PMBOK (2008) incluye un anexo sobre habilidades in-terpersonales que debe desarrollar el jefe de proyecto.

En PMBOK, ni en la ltima edicin ni en las anteriores, existe una visin com-prensiva de la gestin del cambio, probablemente porque se parte de la inter-pretacin de que son materias o decisiones que debe tomar el cliente y queson ajenas al proyecto. Tambin probablemente porque PMBOK es una apro-ximacin generalista para toda clase de proyectos, no un sectorial de TIC y enotros sectores de actividad las necesidades de involucracin del cliente para elxito del proyecto y los problemas relacionados con el uso y adopcin de latecnologa por el cliente no son tan severos.

En todo caso, a lo largo de los siguientes apartados, haremos uso de la referen-cia de PMBOK (2008) cuando la aproximacin sea ms til o, en todo caso,remitiremos al alumno a su lectura o estudio para no perder la consistenciacon el resto de los materiales de este material.


2. La organizacin del proyecto

Entendemos aqu por organizacin la definicin de roles y responsabi-lidades de los miembros del proyecto (cualquiera que sea su proceden-cia: cliente, empresa proveedora, contratistas) con relacin al proyectoy la estructura de toma de decisiones y distribucin del trabajo.

Las estructuras de organizacin incluyen los rganosindividuales (personasque asumen roles y tienen responsabilidades) y tambin los rganoscolegia-dos (comits y comisiones que tienen atribuidas funciones dentro del proyec-to).

Como hemos venido diciendo, en proyectos TIC grandes y complejos, las di-ferencias entre lo que est dentro del proyecto y lo que est fuera, lo que esnegocio y lo que es proyecto, lo que es parte del equipo y lo que son partesinteresadas se difuminan y la gestin del jefe o director de proyecto es, enbuena medida, comprender y manejar ese conjunto de interacciones. Profun-dizaremos en este punto cuando tratemos la gestin de interesados.

2.1. Roles que afectan directamente al proyecto

Sin embargo, s que hay, al menos, tres roles demasiado cercanos al pro-yecto como para dejarlos ahora de lado: la alta direccin, los directoresfuncionales y la oficina de proyecto.

1) La altadireccin que, segn vimos, selecciona y aprueba los proyectosen funcin de unos objetivos y beneficios de negocio, los dota de recursos yasigna al jefe de proyecto.

2) Los directoresfuncionalesydenegocio (entre ellos, el director de infor-mtica) que deben apoyar los objetivos del proyecto en su rea, asignar losrecursos y prestar todo el apoyo necesario para el xito.

3) La oficinadeproyecto (project management office), cada vez ms frecuenteen proyectos grandes, que puede tener un rango muy amplio de funciones,desde el seguimiento y control del cumplimiento de los entregables, presu-puestos y calendario, hasta la gestin de interesados, y que puede tener res-ponsabilidad 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 deella, comprender los requisitos del proyecto o proyectos y gestionar las expectativas(o sea, es casi en s mismo un proyecto!).

Despus de decenios de implantacin de oficinas de proyectos TIC, en Estados Uni-dos, aproximadamente slo la mitad de los directores de organizacin y sistemas(CIO) se muestran satisfechos con su rendimiento en una encuesta publicada en CIOMagazine. Los que se muestran satisfechos lo hacen porque piensan que la oficina deproyecto ha ayudado a implantar estndares de gestin de proyecto, mejorar la satis-faccin 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 simplifica-remos, es que cada vez es ms habitual encontrar organizaciones de proyectodonde se produce una cierta relacin especular (de espejo) entre la estructuradel cliente y la estructura del proveedor o proveedores. Es decir, si el provee-dor tiene un jefe de proyecto, el cliente tiene un jefe de proyecto. Si el pro-veedor tiene un responsable funcional y otro tcnico, el cliente tiene un res-ponsable funcional y otro tcnico. Si el proveedor tiene un responsable parala integracin, el cliente tiene un responsable para la integracin. Esto sueletener grandes ventajas desde el punto de vista de la comunicacin y relacincon el cliente, pero a veces hace la organizacin del trabajo muy compleja yla autoridad se diluye.

2.2. Roles principales en el proyecto

Dentro del proyecto, hay tres roles clave: el patrocinador, el gerente ojefe de proyecto y los miembros del equipo.

1) El patrocinador, o sponsor, normalmente tiene un papel de direccin estra-tgica y relacin dentro del proyecto y con relacin a terceros. Es el promotorde la definicin del proyecto, conoce bien los objetivos y las prioridades y elimpacto en el negocio. Asegura que el equipo tiene la dotacin adecuada encantidad y calidad y se ocupa de motivarlo. Por ejemplo, en la implantacin deun ERP de gestin integral de recursos humanos, el sponsor sera normalmenteel director de recursos humanos de la empresa.

2) El gerente o jefedeproyecto tiene la responsabilidad de supervisar y con-trolar la ejecucin del proyecto para asegurar su cumplimiento en objetivos,tiempo y coste. Asume tambin las relaciones ordinarias con el equipo de laempresa contratada, en su caso, que suele tener a su vez un director de proyec-to, responsable de todos los recursos puestos a disposicin por el contratista ylos subconstratistas. Por su importancia dentro de esta materia, dedicaremosa esta figura un apartado a continuacin.

Nota

Seguiremos aqu principalmen-te el manual de Rodrguez,Garca y Lamarca (2007).


3) Los miembros del equipo tienen una responsabilidad principalmente tc-nica, de ejecucin de la parte del trabajo que tienen asignada con su aporta-cin profesional y en colaboracin con otros miembros del equipo y personaldel cliente. Suelen tratar las operaciones con un supervisor o lder intermediodel proyecto, y stos, con el gerente. Actualmente, los miembros del equiposuelen pertenecer a la organizacin del cliente, a su departamento de infor-mtica y a empresas externas.

Cada figura juega un papel diferente en cada fase del proyecto. En general,corresponde a la alta direccin la aprobacin del proyecto, por s misma oconjuntamente con el Comit de Direccin o las direcciones funcionales afec-tadas. El patrocinador del proyecto es un director funcional (o el director deinformtica) y normalmente realiza las propuestas para la aprobacin y es elque decide en la fase de definicin del proyecto. El responsable operativo delproyecto, una vez aprobado y definido, es el gerente o jefe de proyecto, quiendebe decidir (en el entorno establecido de contenido, coste y tiempo) en lasfases siguientes hasta el cierre.

Cuando se producen desviaciones sobre la definicin del proyecto, su aproba-cin depende del patrocinador del proyecto, las direcciones funcionales o ladireccin general, segn el tipo de problema. Normalmente, el jefe de proyec-to y los miembros del equipo trabajan y toman decisiones en el nivel de lasactividades. El resto de la estructura hacia arriba, toma decisiones en el nivelde hitos y entregables (EDT).

2.3. El director o jefe de proyecto

El jefe de proyecto es el responsable del proyecto en el da a da. Tieneque organizar el trabajo dentro del equipo de proyecto y en sus relacio-nes con la organizacin cliente. Es la persona que dirige el proyecto des-de la planificacin hasta el cierre (a veces interviene tambin en las fasesanteriores), y tiene la responsabilidad del cumplimiento de objetivos entiempo y costes y de los recursos asignados para ello. Para cumplir conxito su funcin, debe estar investido de la autoridad equivalente a suresponsabilidad.

El papel del jefe de proyecto es gestionar. Gestionar un proyecto TIC consisteen lo siguiente:

Hacer que las cosas se hagan en colaboracin con otros.

Marcar un camino y hacer que la gente se mueva en esta direccin conxito.


Mejorar el rendimiento individual y del grupo mediante el consejo y laevaluacin.

Relacionar al equipo con la organizacin, con otros equipos y con el clien-te, y facilitarle informacin y recursos.

Tener y compartir una visin amplia del proyecto dentro de la empresa, yentender los beneficios del proyecto para el cliente y lo que la tecnologaaporta al negocio.

Gestionar requiere, por lo tanto, un conjunto de habilidades interpersonales,a las que nos referimos en un apartado posterior de este mdulo. Un buen ldermuestra una visin y una direccin clara, genera confianza y crea sentimientode pertenencia y deseo de estar en el equipo, ayuda en el desarrollo personalmediante el coaching, tiene a veces algunas cualidades especiales o carisma yadems tiene competencias tcnicas que el equipo reconoce.

En todo caso, como dicen Andersen y otros (2003), es de poco valor o un pocofrustrante ir comparando a la gente que hace proyectos y listas de super-cua-lidades. Es ms importante entender cules son los requisitos esenciales delpuesto, con independencia de las cualidades personales y directivas. Un buenjefe de proyecto:

Puede hacer una valoracin realista del estado del proyecto, tanto con re-lacin al cumplimiento de los hitos y el progreso del trabajo, como conrelacin a la situacin de las personas del equipo.

Puede proponer y ejecutar acciones y decisiones para corregir la situacinsi hace falta, de forma flexible y efectiva, para el xito del trabajo y de lagente.

Puede comunicar lo anterior de forma adecuada en el contenido, en laforma y en el tiempo, para obtener la comprensin y el apoyo de todaslas partes involucradas.

Este balance de madurez, flexibilidad y realismo entre las necesidades del pro-yecto y las de las personas es lo ms importante en el jefe de proyecto. Un buenjefe de proyecto no es un tecncrata (el mejor conocedor e implantador dela solucin tecnolgica), un burcrata (el mejor controlador y metodlogo dela gestin 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 accin.

Quin deber ser jefe de proyecto

Normalmente, un jefe de proyecto ha sido antes miembro de un equipo, por lo ge-neral un miembro exitoso, y ha aportado su conocimiento funcional o tcnico alequipo. Aunque el jefe de proyecto tambin tiene una aportacin tcnica, no est ah


principalmente para esto y no es verdad que el gerente sea "el que ms sabe". En losproyectos TIC, es habitual que el jefe de proyecto tenga una formacin o experienciatcnica. Esto facilita la relacin con el equipo y el conocimiento de las metodologas,tcnicas y herramientas que se utilizan en el trabajo.

Pero no tiene que ser necesariamente as. En otras ocasiones, el sponsor prefiere esco-ger una persona de su organizacin o departamento, que conoce bien el negocio y losprocesos de trabajo. Para complicar el dibujo, las empresas externas que colaboranen la realizacin del trabajo y los subcontratistas de la empresa adjudicataria tambincolocan 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 documentarel rol de cada uno. Aunque puede variar en cada situacin, nos inclinamos por elsiguiente modelo:

Un director o jefe de proyecto de la organizacin que realiza el encargo, con for-macin y experiencia gestionando proyectos, y que sea informtico o con cono-cimiento y capacidad de dilogo en ese mbito. Le corresponde la supervisinglobal del trabajo y tomar las decisiones que se han descrito, por s mismo o con-juntamente, con alguna de las siguientes figuras.

Un lder funcional, extrado del rea de negocio, que representa los intereses (ob-jetivos) del patrocinador con relacin al proyecto, conoce el negocio y los pro-cesos. Asigna, controla y motiva a los miembros del equipo que proceden delcliente.

Un jefe de proyecto de la organizacin contratista, responsable del cumplimientode los objetivos descritos en el contrato. Controla y motiva a los miembros delequipo que le han sigo asignados y a las empresas subcontratistas, en su caso.

Este 'triunvirato' asume actualmente, en las organizaciones y proyectos complejos,la 'direccin' del proyecto.


2.4. El Comit de Direccin

El jefe de proyecto reporta normalmente a un comit de direccin, don-de estn representadas las diferentes partes interesadas en el xito delproyecto, que aportan recursos y que tienen que tomar decisiones. Nor-malmente est presidido por el sponsor o patrocinador.

Corresponde al comit:

Aprobar el plan de hitos y descomposicin del trabajo (EDT). Aprobar el reparto de roles y responsabilidades en el proyecto. Asegurar la asignacin de recursos. Asegurar la comunicacin dentro de la organizacin 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, presupues-

to y tiempos.

En principio, no es bueno que el comit de direccin sea decisorio y no sonbuenas las decisiones tomadas en comits. La organizacin de un proyectodebera ser fundamentalmente jerrquica y las decisiones deberan tomarse enlos rganos individuales del proyecto o, si le sobrepasan, en las rganos direc-tivos de la compaa. Sin embargo, en organizaciones y proyectos complejos


es casi inevitable un nivel de coordinacin y transaccin entre unidades o ne-gocios independientes, con objetivos distintos y que aportan diferentes recur-sos. Deben aceptarse los costes de transaccin de estas situaciones, las reglasdel juego (en especial, el procedimiento y el tiempo para tomar decisiones),establecer una cultura de trabajo en equipo (diferente de las responsabilidadesde lnea, propias de la organizacin convencional) y desarrollar, por parte delsponsor y del jefe de proyecto, las habilidades de comunicacin y negociacinque esto requiere.

2.5. La matriz de roles y responsabilidades

Cada proyecto es diferente, ocurre en una organizacin distinta, con reglasnicas, atiende problemas de negocio especficos y tiene componentes tcni-cos y personales diversos. Es importante dedicar tiempo a entender todo estoy a disear la mejor manera de resolver los problemas e integrar a todos loscomponentes y establecer un dilogo constructivo con el cliente y luego den-tro de los equipos de trabajo sobre todos los aspectos organizativos. Muchosproyectos fallan (no cumplen sus objetivos), o son ineficientes (se utilizan mallos recursos) o resultan frustrantes para los equipos porque no se clarifica lamejor contribucin de cada miembro, la relacin entre ellos, las relacionescon el cliente y no se toman las decisiones adecuadas, a tiempo y por quiendebe hacerlo.

El plan de gestin de recursos humanos, elaborado en la etapa de pla-nificacin, debe proporcionar una definicin clara de los recursos hu-manos asignados al proyecto, en cantidad y calidad, el papel de cadauno sobre los productos y actividades, las necesidades de supervisin ycontrol y el momento de entrada y salida del proyecto.

Con relacin al papel de las personas dentro del proyecto, deben clarificarsevarios conceptos diferentes, que en ocasiones se confunden (PMBOK (2008,pgs. 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 fronterascon otros roles. (De nuevo, el ingls es ms rico y preciso que el espaoly el cataln en estos temas. El rol representa lo que en ingls se llamaaccountability, que quiere decir, "dar cuentas de", o sea, a quin hay quepremiar si algo nico y distinguible sale bien, o reprochar si algo no salebien.)

Autoridad: la autoridad tiene que ver con los derechos formalmente asig-nados a alguien de aplicar recursos, tomar decisiones y firmar o rechazar

Nota

Seguimos en este apartado aPMBOK (2008, pgs. 220-223)y Rodrguez, Garca y Lamarca(2007, pgs. 133-135).


aprobaciones. Lo mejor ocurre cuando responsabilidad y autoridad vanjuntas. Responsabilidad sin autoridad suele ser una mala combinacin.

Responsabilidad: responsabilidad es el espacio, el mbito de trabajo quecada uno tiene que desarrollar dentro del rol que tiene asignado para com-pletar las actividades o productos que le tocan en el proyecto. (Todos losmiembros del equipo tienen un mbito de responsabilidad, pero puedenno ser "accountable", no son los que tienen que dar cuentas, porque lohar un superior, normalmente.)

Competencia: es la habilidad o capacidad que tiene alguien para haceralgo. Nadie debera ser asignado para hacer algo que no sabe o no puedehacer y, si inevitablemente tiene que ser as, debe ser por poco tiempo ycon la ayuda, formacin y supervisin adecuada. El plan y la gestin derecursos (en particular, el proceso de asignacin de equipo) debe asegurarque el proyecto se dota de las personas con las competencias adecuadas.

La matriz de roles y responsabilidades es el mejor instrumento para mostrar laasignacin de roles dentro del proyecto y en las diferentes fases, especialmenteen proyectos complejos en los que participan mltiples departamentos, per-sonal interno y externo, contratistas y subcontratistas.

En el eje vertical se mostrarn las diferentes materias a resolver (normalmen-te, los hitos o actividades del proyecto). En el eje horizontal, los diferentesmiembros que participan. Normalmente, en el nivel de hitos o EDT se recogeel personal directivo del cliente, diferentes departamentos y proveedores y losroles directivos dentro de la empresa contratada, si es el caso. En cada casilla,se representan los roles.

En su forma ms sencilla, la matriz RACI, los roles son slo cuatro:

1) Responsible (ejecuta): el encargado de realizar o ejecutar el trabajo.

2) Accountable (responsable): el responsable ltimo, el supervisor, el que tienela autoridad, toma decisiones o tiene que dar cuentas sobre el trabajo realizado.

3) Consult (esconsultado): alguien que debe ser consultado y apoyar el tra-bajo.

4) Inform (esinformado): alguien que debe ser informado.

En la tabla siguiente (tabla 2) mostramos un ejemplo de matriz RACI para untrabajo tpico de desarrollo de un sistema de informacin.

Matriz de roles

Tambin se llama matriz RAM(responsability assignment ma-trix) y matriz RACI (de las siglasresponsible, accountable, con-sult, inform).


Tabla 2. Ejemplo de matriz RACI

En la prctica, en los proyectos actuales, la cantidad y sofisticacin de rolesha aumentado. En la aproximacin GDPM (gestin de proyectos orientada aobjetivos), de Andersen y otros (2003), se establece un nmero ms complejode roles que se muestra en la tabla siguiente (tabla 3).

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 opinin o consejo si se requiere

Andersen y otros, 2003

Un resultado prctico en un nivel de detalle inferior se muestra en la tabla 4para el ejemplo de planificacin de un portal de atencin al ciudadano quevimos en el mdulo "Planificacin del proyecto".


Tabla 4. Ejemplo de tabla de descomposicin de actividades con asignacin de roles

La matriz de roles y responsabilidades, cualquiera que sea el formato elegido(PMBOK, 2008), proporciona otros formatos adems de los mostrados aqu, ydebe considerarse uno de los documentos bsicos de la carpeta de proyecto, almismo nivel que el plan de proyecto, el acta de constitucin o los documentosde aceptacin de los productos.


3. Gestin de interesados

Los interesados en un proyecto (o stakeholders, en ingls) son todas las perso-nas y organizaciones que se vern afectadas por el desarrollo del proyecto, seadirectamente, porque participan en el proyecto de alguna manera, o indirec-tamente, porque el funcionamiento del producto o servicio que resultar delproyecto les afectar de una forma u otra. (La gestin de interesados es unaparte importante de la "gestin del cambio".)

A lo largo del proyecto, la gestin de interesados aspira a identificarloscorrectamente, entender sus expectativas e inters en el proyecto, ca-lificar su influencia dentro de la organizacin y establecer estrategiaspara su manejo para facilitar la participacin de aquellas personas queson necesarias para el xito y, en general, la aceptacin del proyecto ylos productos o minimizar las barreras de adopcin en el seno del clien-te. Esto no es sencillo, porque entre las partes existen frecuentementeintereses en conflicto, latentes o explcitos, que el proyecto hace msevidentes.

El proceso de gestin de interesados, segn hemos comentado, est incluidoen PMBOK (2008), en el rea de conocimiento de comunicacin y se desarrollaen la etapa de iniciacin y en la de ejecucin.

La gestin de las expectativas de los interesados, segn PMBOK

Gestionar las expectativas de los interesados incluye actividades dirigidas hacia laspartes interesadas en el proyecto para influir en sus expectativas, atender a sus preo-cupaciones y resolver incidencias (issues), tales como:

Manejar activamente las expectativas de los interesados para aumentar la proba-bilidad de aceptacin del proyecto, negociando e influyendo sobre sus deseos pa-ra conseguir y mantener los objetivos del proyecto.

Atender a sus preocupaciones (concerns), que todava no se han convertido en in-cidencias (issues), para anticipar problemas futuros. Estas preocupaciones necesi-tan ser puestas encima de la mesa y discutidas y examinados los riesgos.

Clarificar y resolver las incidencias (issues) que han sido identificadas. La resolu-cin puede resultar en una peticin de cambios o puede ser atendida fuera delproyecto, en otra fase o en otra instancia de la organizacin.

Fuente: PMBOK, 4. ed. (2008, pg. 261)

Genricamente, se pueden considerar interesados los siguientes grupos:

Losusuarios son las personas internas o externas a la organizacin quedebern usar los sistemas o tecnologas que se estn implantando. Existen


muchos niveles, capas o tipos de usuarios, y es muy importante entenderel proceso de adopcin (aceptacin y uso efectivo) de la tecnologa en cadacaso.

Losdirectoresfuncionalesodenegocio afectados por el proyecto, seacomo usuarios, por su relacin o influencia en el proceso de negocio, porsu aportacin de recursos o porque el proyecto modifica su estatus o res-ponsabilidad. Uno o varios directores funcionales, segn vimos, puedenser el sponsor o patrocinador del proyecto, en cuyo caso, son ms una partedel proyecto que un interesado (y es importante que lo entiendan as yjueguen ese rol activamente).

LosdepartamentosdeTIC u otros relacionados con la organizacin y lossistemas de informacin, que pueden variar en cada organizacin. Confrecuencia, se encontrarn en un rol doble, como interesados o afectadospor el proyecto (que afectar a sus responsabilidades, carga de trabajo, ca-pacidades y cuota de poder, casi siempre) y, al mismo tiempo, sern partedel proyecto y debern aportar conocimiento y recursos. Suelen ser intere-sados especialmente complicados de manejar.

LosproveedoresdeproductosyserviciosTIC, en primer lugar los rela-cionados con el proyecto, pero eventualmente otros dentro del cliente,como los que proporcionan los servicios de soporte de usuarios, gestinde las redes, mantenimiento de aplicaciones y todos los que gestionan lasaplicaciones heredadas (legagy, en ingls) a las que los productos del pro-yecto sustituyen o con las que se integran. Para muchos, el proyecto esuna amenaza.

Losjefesdeproyectofronterizos o relacionados con el nuestro, as comolas oficinas de programa (en aquellas organizaciones acostumbradas a ges-tionar 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 gestin del cambio,estarn involucrados muchos otros miembros del equipo de direccin, co-mo la direccin de recursos humanos, responsables de oficinas locales oregionales y probablemente la alta direccin.

3.1. Los aspectos polticos de cualquier proyecto

En primer lugar, el estudiante y profesional de las TIC, y ms an si le toca ju-gar el rol de jefe de proyecto, necesita reconocer desapasionadamente el papelque la poltica tiene en las organizaciones, y que los proyectos (y sus productosresultantes) alteran inevitablemente los equilibrios de poder vigentes. Las TICpueden ser un producto neutro, no lo discutiremos ahora y aqu, pero desdeluego no lo es su uso. Sin reconocer (y seguidamente gestionar) los compo-

Ved tambin

En el mdulo "Iniciacin delproyecto y trabajos previos",cuya revisin recomendamosahora, hemos indicado algu-nos procesos y tcnicas deidentificacin, registro y califi-cacin de interesados propiosde la etapa de iniciacin.


nentes polticos de cualquier proyecto TIC, es imposible entender la mayorade 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 esreconocer que l tambin tiene intereses, emociones, preferencias, apegos ydesapegos, que se ponen en juego durante la realizacin del proyecto. No esuna estatua de hielo a salvo de sus intereses y emociones y todos stos influyenen sus relaciones, en su interaccin con las personas e, inevitablemente, en susdecisiones. Es bueno, por lo tanto, que aprenda a reconocerlos y a mostrarloshonradamente, si quiere hacer algo con ellas y ellos y que se conviertan en algoproductivo para el trabajo, el equipo y el cliente. Las actitudes ingenuas (tantocomo las actitudes deshonestas, del "tiburn" o pescador en ro revuelto) nosirven para nada.

Pinto y Millet (1999) resumen en cinco proposiciones, sustentadas por la evi-dencia cientfica, una visin desapasionada, tranquila y natural de lo que pasaen cualquier organizacin cuando ocurre un proyecto y, con el proyecto, lasdecisiones de asignacin de recursos, reparto de responsabilidades y cambiosen los procesos y organizacin del negocio y en las formas de trabajar:

1) Las decisiones importantes en cualquier organizacin se refieren a la asig-nacin de recursos escasos. La decisin de hacer o no un proyecto TIC y quproyecto se hace compite con otras demandas de la organizacin. Alguien ga-na y alguien pierde.

2) Durante el proceso de asignacin de recursos y toma de decisiones, se pro-ducen negociaciones, que tienen componentes racionales y otros emociona-les. Nadie gana todo o pierde todo. Se establecen compromisos y victorias yderrotas parciales, entre gente que est condenada a entenderse, trabajar juntay establecer alianzas.

3) Ninguna organizacin es monoltica. Cada organizacin est compuestapor grupos y coaliciones de intereses, incluso cuando existe una cultura y au-toridad corporativa fuerte y compartida. Incluso cuando se produce una de-cisin corporativa, compartida, consensuada y negociada, es normal que apa-rezcan conflictos de inters o rechazo por parte de algunos grupos de la orga-nizacin que pueden entender que su posicin se debilita o se daa, real opotencialmente.

4) Estos grupos de inters difieren en objetivos, valores, actitudes, prioridades,agenda y en otras muchas cosas. Estos grupos pueden ser departamentales (fi-nanzas frente a marketing), geogrficos (Europa frente a Amrica) o de origeno formacin (en las fusiones, por ejemplo). Este proceso se llama "diferencia-


cin organizativa". Por este motivo, los grupos con frecuencia pueden estarinclinados a satisfacer en mayor medida sus propios intereses que los de ladireccin o los de la empresa como un todo.

5) Como corolario, debido a la escasez de recursos, las heridas y com-promisos que produce la negociacin y las diferencias e intereses priva-dos de los grupos, la discusin sobre el poder o la aparicin del conflictono son efectos secundarios, indeseados o evitables, sino que son algocompletamente racional, lgico y normal en cualquier organizacin.

Por nuestro lado, aadiramos que la aparicin de un proyecto TIC, en espe-cial si es grande, complejo, si afecta al negocio y si atraviesa diferentes depar-tamentos o negocios dentro de una corporacin, introduce un desequilibrioen las estructuras ms o menos estables de distribucin del poder que hacean ms inevitable y central la aparicin de conflictos. En efecto, la evidenciamuestra, de nuevo citando a Pinto y Millet (1999), que contra lo que podra-mos imaginar el comportamiento poltico es mucho ms frecuente en algu-nos mbitos como los proyectos de cambio estructural o las implantaciones denuevos sistemas de informacin, que por ejemplo en el manejo de las quejasdel personal.

Y no pasa nada. Lo que hay que hacer es reconocerlo, entender la influenciae impacto de cada parte sobre el proceso de adopcin y gestionarlo adecuada-mente.

3.2. Cmo se gestiona la poltica en el proyecto

Lo primero, insistamos, es reconocerla. Y establecer el proceso, las herramien-tas, 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

Gestionar la poltica

Confiar en "la comunicacin",como hace PMBOK (2008) yotras metodologas, la distri-bucin de la informacin, unbuen lanzamiento de proyectoy presentaciones eficaces for-ma parte de la aproximacinque hemos llamado ingenua.


Lo segundo es ver que cada grupo requiere una estrategia diferente y que noson tantos.

No parece que debamos dedicar mucho tiempo a los neutros ni a aquelloscuya colaboracin no necesitamos (si acaso, mantener las antenas abiertaspor ver si pueden pasar al grupo de opositores o si de pronto les necesita-mos), ni tampoco a aquellos cuyo impacto e influencia es bajo. El proble-ma y la oportunidad la tenemos en aquellos cuyo impacto e influencia esalto (y acaso medio), cuya cooperacin es necesaria y cuya posicin es deentusiasmo o de oposicin. Esos son nuestro objetivo y a los que debemosdedicar tiempo y esfuerzo.

Un entusiasta, cuya cooperacin es necesaria y que tiene un impacto alto,puede ser un campen (en ingls, champion) interno del proyecto, alguienque har de propagandista, convencer a los neutrales y debilitar a losopositores. Necesitamos champions.

Con relacin a los neutrales y los opositores, es imprescindible reconocerque nadie tiene por qu compartir nuestro entusiasmo de entrada y quees lgico que vean las dificultades y barreras antes que los beneficios. Be-neficios y barreras tienen que ser personalizados. El jefe de proyecto tieneque entender para cada interesado clave algo muy sencillo: "qu gano yocon esto?" (en ingls, le llaman la tcnica WIIIFM, what is in it for me?). Siel proyecto es capaz de responder esta pregunta pronto, con ejemplos ovisitas a otros clientes, con prototipos, mostrando el soporte y apoyo enla implantacin y post-implantacin, tendremos mucho ganado. Tambinsuele ser prctico dejar de invertir o mantener los sistemas heredados ymostrar las deficiencias de los sistemas actuales.

La gestin de los opositores recalcitrantes a veces requiere cierta durezay es bueno que as sea. Su posicin debe ser sistemtica y objetivamentedebilitada en las reuniones colectivas, debe buscarse su aislamiento o, sisu participacin es imprescindible y sta no se est produciendo en la for-ma debida, incluso pedir su sustitucin al sponsor del proyecto o a la altadireccin. El cliente y la misin del proyecto son lo primero y no podemospermitirnos nada que los ponga en riesgo.

Frecuentemente, los interesados, una parte de ellos o de su personal, sonmiembros de los equipos de proyecto o tienen alguna participacin en deter-minadas fases. Si son tratados como parte del equipo, si comparten los objeti-vos y cooperan entre s, si trabajan fsica e intelectualmente juntos resolvien-do problemas, si comparten un ambiente cohesionado y motivado, es muyprobable que su aceptacin del proyecto, la comprensin de las dificultades yel esfuerzo extra de la transicin aumenten y, con ello, el xito del trabajo.

Laadopcindelatecnologa


S, la comunicacin es importante, pero la comunicacin importante es la quese refiere a lo que el proyecto dar y lo que no dar y en qu condiciones, y encompartir con el cliente al mximo nivel cules son, en ltimo extremo, lascondiciones de xito del proyecto. En esto es en lo que ms se suelen equivocarlos profesionales de las TIC y las empresas de servicios y la mayor causa defrustracin de los clientes, como ya hemos dicho.

El xito del proyecto, en ltima instancia, no consiste en la aceptacin de losentregables y el cobro de las facturas, sino en tres elementos que suelen escapardel proyecto, en el alcance y en el tiempo (Pinto y Millet, 1999):

1)Queelsistemalousequienlotienequeusaryparaloquelotienequeusar (el caso ms llamativo en el mbito de las telecomunicaciones han sido lassuper-autopistas de la informacin, infrautilizadas durante ms de una dcada,o el de la mayora de las aplicaciones web transaccionales pblicas y algunasprivadas, pensadas desde la oferta y no desde la demanda). La comprensin yla gestin del proceso de adopcin de la tecnologa por los usuarios internosy externos es clave.

2) Una implementacin exitosa de productos o servicios TIC requiereinevitablementemodificaciones,tantoenelproductocomocambiosenelcliente. Existe un proceso de adaptacin mutua, que tiene que ver con la"gestin de los cambios" en el proyecto y con la "gestin del cambio" en elcliente.

3)LosbeneficiosrealesdeunproyectodeimplantacindesolucionesTICseobservanconeltiempo, cuando el cliente los ha incorporado plenamentea sus operaciones y ha realizado los cambios necesarios en sus procesos de tra-bajo. Es muy difcil evaluar el xito de una implantacin al acabar el proyectoy con la aceptacin de los entregables.

La difusin de las innovaciones

El proceso de adopcin de la tecnologa por los usuarios internos y externos es muydesconocido 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 sesionesde formacin. Pero se ha estudiado para otras tecnologas y profesiones (en especial,desde la aparicin de la obra de Everett Rogers, Diffussion of Innovations en 1965) y,en los ltimos aos, tambin para las tecnologas de la informacin, tanto en entor-nos limitados (en el interior de las organizaciones) como en entornos masivos (porejemplo, para usuarios de soluciones web abiertas al pblico).

Segn la teora de Rogers, cualquier innovacin sufre un proceso de adopcin socialque atraviesa una serie de estadios, en los cuales diferentes proporciones del pblicoobjetivo asimilan y usan la innovacin, hasta que la adopcin es casi completa dentrodel sistema social al que va dirigida. De acuerdo con este modelo es posible identificarcinco grupos de adoptantes (los innovadores, los adoptantes tempranos, la mayoratemprana, la mayora tarda y los rezagados) que se distribuyen en una proporcinde frecuencias que adopta una forma similar a una curva normal. La inclinacin dela curva est determinada por la velocidad (el ratio de adopcin) en que el proceso deadopcin se produce (figura 4). Una masa crtica de usuarios (y por tanto, un procesosin retorno) se consigue cuando se alcanza el 50% de la demanda.

Bibliografarecomendada

E.M.Rogers (2003). Difusionof innovations (6. ed.). NuevaYork: The Free Press.


Figura 3. El proceso de adopcin de las innovaciones

Fuente: E. Rogers (2003). Diffussion of Innovations (5. ed., 1995, 2003)

Si analizamos el proceso individual de adopcin, ste dependera principalmente deaspectos relacionados con el producto, el contexto situacional y la relacin con otroscompradores. Por ejemplo, en aplicaciones tecnolgicas, la percepcin de utilidad, lapresin de otros usuarios o partes de la cadena, la adopcin por lderes de opininy un contexto de autoridad suele facilitar la adopcin en un contexto organizativo.En cambio, en Internet, parece que la adopcin de una aplicacin est ligada a lapercepcin de utilidad, la frecuencia e intensidad de uso, la sensacin de seguridady la experiencia individual del usuario, por ejemplo, con relacin a la usabilidad ytiempo de respuesta.

El proceso de adopcin sigue un ciclo que pasa por los estadios de 1) conocimiento dela oferta, 2) desarrollo del inters y predisposicin a la prueba, 3) decisin y ejecucinde la prueba, y 4) compra repetida o leal.

A travs de tcnicas adecuadas, es posible analizar la situacin de nuestros usuariospotenciales con relacin al proceso de adopcin y actuar sobre cada grupo medianteuna diferente mezcla de tcnicas, adems de las de autoridad, que proceden funda-mentalmente del mundo del marketing y la comunicacin empresarial.


4. La comunicacin

Desde el inicio de este material hemos venido diciendo que gestionar proyec-tos quiere decir dos cosas:

1) Asegurar que los proyectos se completan satisfactoriamente y que se consi-guen sus productos y resultados ltimos, en alcance, tiempo, costes y calidad(incluyendo la aceptacin y uso por el cliente).

2) Hacerlo de manera que se pueda predecir y controlar su evolucin y expli-carlo satisfactoriamente al equipo de trabajo y al cliente.

Tan importante como hacer bien el proyecto, decamos, es poder y saberloexplicar y asegurar su comprensin.

La comunicacin es central en el proceso de gestin de proyectos y afec-ta a todos los procesos y reas de conocimiento. Si gestionar un proyec-to es gestionar la relacin con las personas (el cliente, el equipo, la or-ganizacin en la que servimos), la relacin con las personas se basa enla comunicacin.

La comunicacin en el eje del proceso de consultora

"Cuando me inici en la profesin de consultor en 1989, lo hice en una firma deconsultora estratgica y de la mano de gente que provena de Booz, Allen and Ha-milton (hoy Booz and Co.) en el Reino Unido. La primera formacin que recib fuesu aproximacin o mtodo (jams le llamaron "metodologa") de gestin del procesode consultora, en definitiva, de hacer proyectos.

Recuerdo que la representacin grfica del proceso era una rueda con varios radios (si-milar a la que se usa a veces para representar las "reas de conocimiento" de PMBOK),en cuyo eje estaba la COMUNICACION. La comunicacin se relacionaba con todoslos dems procesos y etapas del trabajo y se planificaba al comienzo del proyecto,incluso antes, en las fases de aproximacin comercial y preparacin de propuestas.

Desde el comienzo del trabajo, por ejemplo, se trabajaba con la visin final de losinformes y presentaciones al cliente, que se diseaban y se iban completando desdemuy pronto, de manera que en cualquier momento se estaba en condiciones de pre-parar con poco esfuerzo un producto intermedio.

La formacin que recibamos para hacer entrevistas, reuniones de trabajo, presenta-ciones o informes era mucho ms importante que otra formacin tcnica o en me-todologas especficas. El foco de la supervisin y feed-back de los consultores jve-nes, hasta extremos inconcebibles, era sobre todos los aspectos relacionados con lacomunicacin y "todo lo que comunica" en la relacin con el cliente y el equipo (elvestuario, la posicin corporal, los gestos, el diseo de grficos, tablas, documentosescritos...)".

Jos Ramn Rodrguez


En PMBOK, cada vez se le da mayor importancia al rea de conocimiento dela comunicacin. En su ltima edicin, PMBOK (2008), la gestin de la co-municacin incluye tambin la gestin de interesados y se concentra en lasetapas de planificacin y ejecucin, aunque recorre casi todo el conjunto delproyecto:

En la etapa de iniciacin, con la identificacin de las partes interesadas.

En la etapa de planificacin, con la preparacin del Plan de comunicacin.

En la etapa de ejecucin, incluyendo la distribucin de la informacin yla gestin de las expectativas de los interesados.

En la etapa de control y seguimiento, con la preparacin de los informesde progreso.

Ya se ve que en PMBOK, el planteamiento es posiblemente un poco reduccio-nista y est muy enfocado a los aspectos formales de reporte y distribucin dela informacin, aunque si se trabaja a lo largo de la ltima edicin del manual,se encuentran aproximaciones y hallazgos de un calado mayor, como veremosseguidamente.

Los procesos de comunicacin interaccionan de manera intensa con el restode los procesos de gestin de proyecto, se superponen entre s y con los demsy son iterativos. Los procesos, tcnicas y herramientas de comunicacin noslo son formales: en el proyecto, todoytodoscomunican.

4.1. El proceso de comunicacin

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

Comunicacin interna (dentro del equipo) y externa (con el cliente, losinteresados y otros pblicos).

Comunicacin formal (documentos del proyecto) e informal. La comuni-cacin informal puede ser a su vez oficial o reservada (off the record).

Comunicacin oral y escrita.

Comunicacin verbal y no verbal (las inflexiones de la voz, los gestos, laexpresin corporal).

Comunicacin vertical (hacia arriba o hacia abajo) u horizontal (entreiguales).


Asimismo, la comunicacin en gestin de proyectos incluye diferentes capa-cidades, muchas de ellas comunes a la comunicacin empresarial o incluso ala comunicacin general entre personas, pero que en la gestin de proyectos,con sus consecuencias sobre el trabajo, deben manejarse con especial cuidadoy rigor. Son, entre otras, las siguientes (PMBOK, 2008, ampliado):

Escuchar activamente.

Saber preguntar y proporcionar retroalimentacin (feed-back), para asegu-rarse de que se ha comprendido bien la respuesta.

Entender las barreras de comunicacin, lenguaje o expresin y buscar ma-neras de superarlas.

Saber elaborar hiptesis y buscar hechos para identificar, confirmar o re-chazar la informacin que necesitamos.

Expresar con claridad y honradez el propio punto de vista y defenderlo enuna discusin abierta.

Establecer las expectativas con claridad y saber manejarlas.

Convencer o persuadir y, sobre todo, convertir esa persuasin 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 comunicacin tambin es, por lotanto, 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 comunicacin formal y la distribucin de infor-macin dentro del proyecto, aparece tambin un conjunto de tcnicas y habi-lidades a adquirir y gestionar, como las siguientes (PMBOK, 2008, modificadoy ampliado):

Preparacin, manejo y documentacin de entrevistas.

Preparacin, manejo y documentacin de reuniones.

Tcnicas de facilitacin, para construir consenso y superar barreras.

Tcnicas de presentacin oral.


Tcnicas de presentacin escrita, preparacin de informes, grficos y ta-blas.

Eleccin de los canales, medios y tecnologa ms adecuada para comunicaren cada caso.

El modelo bsico de comunicacin

El modelo bsico de comunicacin utilizado en todas las ciencias sociales para lacomunicacin entre dos partes es aplicable tambin a la comunicacin en gestinde proyectos. Segn este modelo, en cualquier proceso de comunicacin existen lossiguientes componentes (figura 4):

Un emisor y un receptor.

Un codificador, que traduce las ideas en un lenguaje que pueda ser comprendidopor las dos partes.

Un mensaje de ida y otro de vuelta. Al mensaje de vuelta le llamamos feed-backo retroalimentacin, que quiere decir en primer lugar un reconocimiento de queel mensaje se ha recibido y se ha entendido.

Un medio o canal a travs del cual se trasmite el mensaje.

Ruido, o sea, cualquier cosa que interfiere la transmisin y comprensin del len-guaje.

Un decodificador, que convierte el lenguaje de nuevo en ideas que puedan sercomprendidas.

Figura 4. El modelo bsico de comunicacin

Fuente: PMBOK (2008)

Corresponde al emisor asegurarse de que la informacin se recibe clara y completa yconfirmar que se ha entendido. Y corresponde al receptor asegurarse de que ha reci-bido la informacin que le han transmitido, de forma completa y clara, y confirmarque lo ha hecho. Para ello se usan tcnicas como la repeticin y la parfrasis ("hasquerido decir que...").

Corresponde a los dos (pero en un proyecto, es una responsabilidad principal deljefe de proyecto) eliminar barreras que introduzcan ruido (rumores, distancia, malosentendidos, problemas tecnolgicos...). A veces estas barreras son psicolgicas o po-lticas, producidas por un sesgo de actitud o de inters. Las mayores barreras para lacomunicacin provienen de "lo que no se dice"; es decir, de la interpretacin que haceel receptor del mensaje, basada en sus experiencias anteriores, su actitud o la actitudque percibe o interpreta del emisor, la aparicin de cdigos diferentes (las mismaspalabras que pueden querer diferentes cosas), factores culturales y de posicin o in-ters con relacin al proyecto.

La necesidad de comunicacin y los riesgos de una comunicacin inadecuada au-mentan de forma exponencial con el nmero de personas que comunican entre s.


Fuentes: PMBOK (2008, pg. 255); Rodrguez, Garca, Lamarca, (2007, pg. 137)

4.2. Algunas reglas bsicas

Acabaremos esta seccin con algunos consejos prcticos, que parecen de sen-tido comn, pero que incomprensiblemente se echan a menudo a faltar enla comunicacin en los proyectos. Si se siguen estas reglas, las probabilidadesde xito a la hora de comunicar bien son muy altas, incluso si no se conocenmodelos o tcnicas sofisticadas:

1) No prometas lo que no ests seguro de poder cumplir. Es preferible prometermenos y superar luego las expectativas del cliente.

2) Cumple lo que has prometido y, si sabes que no lo hars, comuncalo pron-to. En general, informa cuanto antes de las situaciones, incidencias o cambiosque puedan afectar a los resultados del proyecto.

3) Reporta honrada y claramente el estado del proyecto. Prepara bien los ma-teriales y asegrate de que se presentan con claridad, sencillez y elegancia. Re-porta excepciones, cambios y temas sobre los que se debe decidir. Lo demsno importa mucho a nadie.

4) Mantn una confidencialidad absoluta sobre la informacin del proyectoy del cliente.

5) No pongas por escrito lo que no quieres que alguien lea. No confes que undocumento o un correo no se copiar a quien no deseas, por muy confidencialque t creas que es.

6) En temas crticos o de conflicto, limita al mximo la comunicacin escrita.Confronta a tu interlocutor rpida y directamente, en persona.

7) S claro, conciso y especfico en el mensaje que deseas trasmitir y en ellenguaje que utilizas. Exprsalo con conviccin y emocin.

8) Da y pide activamente retroalimentacin para asegurar la comprensin delos mensajes. Al principio, suena raro. Luego, todo el mundo ve las ventajas.

9) Escucha proactivamente. No presupongas. No juzgues. No culpes. Escuchaabiertamente la opinin de otros y comparte la tuya con los dems. Bsate enlos hechos.

10) Es bueno facilitar el consenso y la negociacin, pero eso no est por encimade los intereses del cliente y del proyecto.


11) Las reuniones son buenas. Muchas reuniones no son buenas. Son necesa-rias reuniones cortas, para compartir informacin, reporte y tomar decisiones,con los objetivos claros y los miembros necesarios segn el tema.

12) Prepara con anticipacin las reuniones. Haz las convocatorias con antici-pacin, con un objetivo claro y una agenda con contenidos. Enva la docu-mentacin que deba examinarse con antelacin. Haz actas con los acuerdosy envalas a los participantes.

13) Dedica tiempo a preparar cualquier oportunidad de comunicacin, comolas entrevistas, reuniones, presentaciones e informes. Ensaya.

14) Comprende y acepta las emociones e intereses de todos. Crea un ambienteque facilite su expresin. Observa tambin el lenguaje no verbal y "lo que nose dice". Calla. Deja hablar. Gestiona los silencios.

15) Comprende y acepta tus emociones y las expectativas y barreras que creanen otros.


5. Habilidades interpersonales

La comunicacin en el proyecto, como hemos visto, incluye un conjunto deprocesos, tcnicas y herramientas, pero tambin es una habilidad interperso-nal que debe desarrollar el jefe de proyecto, principalmente, y el resto de losmiembros, tanto para la relacin interna dentro del equipo, como para la re-lacin con el cliente, los interesados y la propia organizacin o empresa enla que uno presta servicios. Seguramente, de todas las habilidades que debedesarrollar el profesional de la gestin de proyectos, la comunicacin es la msimportante.

Pero no es la nica. PMBOK (2008) ha recogido en un apndice de su ltimaedicin un conjunto de habilidades de relacin personal, que ayudarn al pro-fesional a entender mejor las situaciones que se producen en el proyecto y amanejarlas adecuadamente. Estas son:

El liderazgo. Hacer equipo (team building). La motivacin. La comunicacin. La capacidad de influenciar. La toma de decisiones. La sensibilidad cultural y poltica. La negociacin.

5.1. El liderazgo

Puede definirse el liderazgo como la capacidad de mostrar una visin yfocalizar los esfuerzos de un grupo humano hacia un objetivo comn,ayudndoles a trabajar como un equipo. El liderazgo se basa en el res-peto, la confianza y el sentimiento de pertenencia al equipo.

El liderazgo se muestra durante todo el proyecto, pero es especialmente im-portante al inicio del trabajo (cuando el equipo se forma) y, durante la ejecu-cin, en la gestin de las situaciones de conflicto. A lo largo del trabajo, el lderde proyecto es responsable de mantener la visin, la estrategia y la comunica-cin, generar confianza y hacer crecer al equipo, proporcionar entrenamientoy gua a los miembros y evaluar el rendimiento individual y del conjunto.


Aunque puede haber cualidades innatas que faciliten el liderazgo y personasque no estn dotadas o sobresalen en esta capacidad, el liderazgo es una ha-bilidad que se adquiere con la formacin, la observacin, la supervisin y lamadurez en el trabajo.

La tabla siguiente (tabla 5) muestra las caractersticas o cualidades de un buenlder de proyecto.

Tabla 5

Cualidades de un buen lder de proyecto

a) Genera confianza y crea sentimiento de equipo. Los miembros tienen unsentido de pertenencia y de que su aportacin se reconoce, quieren estar all ytrabajar 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, clida y accesible. Mantiene informado al equipo. No acepta trabajos o retos por encima de las posibilidades del equipo. Con-

sigue recursos y reconocimiento de la organizacin.

b) Aporta una visin clara. Los miembros entienden lo que se espera de ellos ydel equipo. Para esto: Tiene una visin global del proyecto, desde el punto de vista del negocio y

de la tecnologa, 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 evaluarresultados globales que a supervisar tareas.

Reconoce el trabajo bien hecho, sabe cmo se hace bien y lo sabe trasmitir. Anticipa los problemas y seala pautas para resolverlos. Toma de decisiones y las toma oportunamente

c) Es un buen entrenador (coach) individual, que facilita el desarrollo del equi-po y de sus miembros mediante el ejemplo, la comunicacin y la evaluacin,pero sobre todo consigue que cada persona tome responsabilidad sobre suparte del trabajo y sobre su desarrollo individual en el proyecto. Identifica la situacin de cada miembro y sus necesidades e intereses de

desarrollo. Ayuda a cada miembro a establecer dentro del proyecto objetivos de desa-

rrollo individual. Reconoce el trabajo bien hecho y el que debe ser corregido, explica el por-

qu con claridad, sin buscar culpas ni culpables, y facilita que el miembrodel equipo desee hacerlo correctamente.

d) Tiene otras "cualidades" (que algunos denominan carisma) que hacen queotros lo reconozcan como lder: 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 solucin de siempre. Suele ser ntegro, mantiene sus promesas, es leal con sus leales y mantiene

siempre elevados estndares profesionales y ticos. Lidera con el ejemplo, no con las palabras.

e) Y adems, "sabe". En proyectos tcnicos y en el mundo de las TIC, un buenlder tiene que aportar tambin competencia tcnica y conocimiento del esta-do del arte en las tecnologas o temas que son objeto del proyecto, y ser capazde 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 ha-bilidades que van muy unidas. Hacer equipo (team building, en ingls)es "el proceso de ayudar a un grupo de individuos, unidos por el senti-miento de compartir un mismo propsito, a trabajar de forma interde-pendiente entre s, con el lder, con las partes externas al equipo y conla organizacin. El resultado de un buen liderazgo y de hacer equipose llama buen trabajo en equipo" (PMBOK (2008), pg. 418). Y buentrabajo en equipo quiere decir confianza mutua, comunicacin abiertay efectiva, un mejor proceso de toma de decisiones, control de proyec-to basado en la honradez y la confianza y, normalmente, un proyectomejor gestionado y de mayor probabilidad de xito.

Hacer equipo, en los proyectos actuales, incluye tambin a personas del clien-te, de los subcontratistas y, eventualmente, de otras partes interesadas, y tam-bin con otros miembros de la organizacin "padre" para la que uno presta susservicios y que ha sido contratada por el cliente.

Mientras que el liderazgo es principalmente una habilidad y se desarrolla prin-cipalmente con la experiencia, las actividades de hacer equipo pueden estarms formalizadas a travs de procesos y herramientas. Estas actividades consis-ten principalmente en la creacin, desarrollo y mantenimiento de un entornode trabajo donde la gente se siente motivada para trabajar como un equipo.Esto incluye, entre las cosas ms importantes:

1)Establecerreglasclarasdecomportamiento (en ingls, ground rules) y unacultura de equipo (estas reglas afectan sobre todo a la comunicacin, inter-cambio de informacin y a la organizacin del tiempo y el espacio, ademsde a los procesos y documentos formales, bsicos y compartidos de la gestindel proyecto).

2)Resolverlosproblemasyconflictos que surjan dentro del equipo.


La gestin de conflictos

El conflicto es inevitable, probablemente es necesario. Un buen diseo de organiza-cin, un buen plan, comunicacin clara, liderazgo efectivo y sentimiento de equiporeducen los conflictos. Pero hay conflictos.

En principio, para mantener la cultura de equipo, los debe resolver el equipo, sin in-tervencin externa; son los temas de "vestuario" en los equipos de ftbol. Un esprituy una cultura abierta de comunicacin minimiza el conflicto y permite resolverlo conms facilidad. Las culturas anglosajonas no tienen aversin al conflicto, las nuestrasnormalmente s.

Buscar culpas y culpables no ayuda a resolver el conflicto, lo agrava y llena al equipo ylas personas de malos sentimientos. Se trata de concentrarse en los hechos, no en laspersonas, y en el presente, no en el pasado. Analizar los temas y sus causas es buenopara no repetir errores, pero sobre todo se trata de establecer las polticas, procesos ynecesidades (de organizacin, de supervisin, de control, de formacin, las que sea),para no repetir errores ni conflictos. Y establecer un ambiente positivo que aleje losmalos sentimientos.

3)Gestionareldesarrollodelequipo en su proceso de evolucin, que, segnlas teoras de desarrollo de las organizaciones, acostumbra a seguir patronesde comportamiento conocidos.

Las fases de desarrollo del equipo

Segn las teoras de desarrollo de la organizacin, en la construccin y formacin deun equipo, se pasa y se debe pasar por cinco fases. Corresponde al director de proyectoobservar e identificar el comportamiento del equipo para gestionar la transicin deuna fase a otra de una manera efectiva y a la velocidad adecuada. Este modelo sellama "la escalera de Tuckman", por ser el autor que lo desarroll:

1) Formacin (forming). En esta fase, el equipo se encuentra por primera vez y aprendelos objetivos del proyecto y el rol y responsabilidad individual de cada miembro. Elequipo apenas existe, los miembros son independientes y no muy abiertos.

2) Tormenta (storming). A continuacin, el equipo comienza a actuar sobre el proyec-to, establecer y compartir una planificacin, intercambiar informacin y tomar de-cisiones tcnicas. Si los miembros no colaboran y se abren a diferentes ideas y pers-pectivas, el ambiente puede ser destructivo y el proyecto puede paralizarse en unafase que es muy crtica.

3) Normalizacin (norming). En esta fase, el equipo se acostumbra a trabajar junto yajusta sus hbitos y comportamientos. Comienza a haber confianza entre sus miem-bros.

4) Rendimiento (performing). En esta fase, el equipo alcanza su ritmo de funciona-miento normal y es capaz de trabajar como una mquina bien organizada. Sus miem-bros son interdependientes y trabajan en las incidencias y resuelven los temas quesalen al paso de forma suave y efectiva.

5) Separacin (adjourning). En esta fase, el equipo acaba el trabajo y se va del proyectoa un proyecto nuevo o a su actividad ordinaria en operaciones.

Fuente: PMBOK (2008, pg. 233).

4)Gestindelespaciofsico. A pesar del desarrollo de las tecnologas y de laglobalizacin, que permite y obliga al teletrabajo, la cultura de equipo crececuando se trabaja en el mismo espacio fsico.


5)Evaluacin. La evaluacin puede proporcionarse de muchas maneras. Elentrenamiento y supervisin en el trabajo y la retroalimentacin inmediata("esto est bien, estupendo; esto no est bien por este motivo, la prxima vezsaldr mejor") es lo ms efectivo dentro del proyecto. Pero adems, los miem-bros del equipo estn sujetos a un proceso de desarrollo profesional, del cualel proyecto es una parte o un peldao relevante. Por lo tanto, deben recibirun plan de los objetivos y lo que se espera de ellos en el trabajo y una o variasevaluaciones de su desempeo.

6)Reconocimientoyrecompensas. El plan de recursos humanos y las reglasde la compaa "madre" deben permitir que el lder de proyecto establezca ob-jetivos asequibles, medibles y controlables, que estn al alcance de todos losmiembros y por los que puedan ser recompensados (en particular, en su ca-rrera profesional, la asignacin de proyectos y la retribucin). Es difcil man-tener el sentimiento de equipo y la motivacin si las polticas y procesos derecursos humanos no recompensan el cumplimiento de objetivos y conductasdeseables y que cualquier miembro del equipo (y no unos pocos, o su jefe)pueden alcanzar.

Estos dos ltimos temas (evaluacin y reconocimiento) son complejos en lasgrandes organizaciones profesionales o empresas de servicios TIC. Por un lado,el lder de proyecto intenta desplegar los mejores instrumentos y habilidadespara generar un equipo de alto rendimiento, cohesionado y que disfrute enel proyecto. Por otro, algunas de las herramientas bsicas de motivacin noestn en su mano o incluso, en el lmite, pueden ser contradictorias o contra-producentes.

Motivar es lograr el compromiso de los miembros del equipo con losresultados del proyecto, con su rol dentro del mismo y con el resto delos miembros. Para ello, se trata de entender qu cosas ofrecen a cadapersona mayores satisfacciones o cules son las que cada uno valorams.

Estos valores suelen ser la satisfaccin en el trabajo, los retos progresivos den-tro de su carrera y dentro del proyecto, un sentimiento interior de autorreali-zacin y de contribucin al proyecto y al equipo, sentimientos de crecimien-to profesional y personal, la compensacin econmica y la promocin en laescala laboral y otra clase de recompensas o reconocimientos a veces moraleso psicolgicos.

Los motivadores varan con la edad, las diferencias culturales, la posicin departida y hasta qu punto estn resueltas las necesidades ms bsicas, segnla clebre pirmide de Maslow.


La pirmide de Maslow

Abraham Maslow (1908-1970) es famoso por su teora de las necesidades humanas. Ensu visin, las necesidades humanas pueden agruparse en cinco categoras jerrquicasascendentes. Cuando una categora de necesidades queda satisfecha, deja de ser unmotivador, que se sustituye por la categora siguiente y as sucesivamente.

Los cinco niveles de necesidades, comenzando por las ms bsicas, son las siguientes:

1) Las necesidades fisiolgicas y de supervivencia, como comer, beber, tener una vi-vienda, vestirse y dormir.

2) Las necesidades de seguridad y de proteccin frente al peligro, como tener untrabajo y un sueldo para vivir.

3) Las necesidades sociales, que incluyen el sentimiento de pertenencia y aceptacinpor el grupo.

4) Las necesidades del Yo, la autoestima y el reconocimiento social, a travs de laconfianza en uno mismo, el poder o el prestigio.

5) Las necesidades de crecimiento personal, es decir, el deseo de aumentar las propiascapacidades, talentos y experiencia, intelectual, emocional o profesional. Este gru-po lleva asociados los sentimientos de autorrealizacin, autoexpresin y autocum-plimiento.

A diferencia del liderazgo formal basado en la autoridad jerrquica, el trabajoen equipo entre profesionales de alta cualificacin formados en mbitos tc-nicos especficos, como son los de las TIC, suele pedir un tipo de liderazgoy motivacin basado en la capacidad de hacer un buen trabajo tcnico, enretos de complejidad creciente y variada en un entorno especializado, en elreconocimiento de sus iguales y en el respeto y confianza hacia las personasque les supervisan. Son los "trabajadores del conocimiento" a los que se referaPeter Drucker y suelen sentirse ms comprometidos con su profesin y con elcontenido tcnico de su trabajo, que con la organizacin a la que sirven, conel cliente, con el proyecto o con el propio equipo. Son individualistas y sensi-bles. A cambio, suele ser personal muy entregado y automotivado por lo quehace, si lo que hace le interesa, bastante leal y le gusta establecer relacionesa largo plazo. El lder de proyectos TIC tiene que tener muy en cuenta estascaractersticas.

El liderazgo en proyectos TIC se muestra ms a travs de la influencia yel reconocimiento que a travs de la autoridad y los procesos formales.La influencia se muestra liderando a travs del ejemplo, hacindose res-petar en su propia rea de conocimiento y experiencia (los profesionalesrespetan a los profesionales y desprecian a los incompetentes), usandoun estilo de direccin flexible y ajustado a cada tipo de pblico, clari-ficando el proceso de toma de decisiones y el por qu de una decisindeterminada y siendo cuidadoso en las formas. Es necesario apostar porla relacin a largo plazo y no dejar que se deteriore por un conflicto oun desentendimiento puntual.


5.3. La toma de decisiones y resolucin de problemas

Issues, cambios, riesgos... son problemas y oportunidades para el gerente, querequieren su intervencin (o a veces, una decisin deliberada de no interve-nir y dejar que sea el propio equipo el que resuelva el problema). Ejecutar eseso: decisin, accin. El jefe de proyecto puede tomar las decisiones indivi-dualmente o involucrar al equipo, segn su estilo de direccin y las reglas decomportamiento (ground rules) explcita o implcitamente establecidas, perono es conveniente cambiar de criterio segn le convenga.

En todo caso, las decisiones estn influidas por factores de tiempo, calidad dela informacin con la que se cuenta, confianza o confiabilidad de sus fuentesy criterios de aceptacin o aceptabilidad.

Es bueno que el plan de proyecto y sobre todo los aspectos de organiza-cin del trabajo que hemos comentado en este mdulo (la asignacinde roles, responsabilidades y autoridad en rganos individuales o colec-tivos) establezcan con claridad quin puede decidir sobre qu, cundoy cmo.

Por lo tanto, aqu nos referiremos a aquellas decisiones que afectan a aspectosdel proyecto distintos de la resolucin de incidencias ordinarias del da a da ysobre las que el lder de proyecto tiene autoridad para decidir o para proponera un rgano superior.

La toma de decisiones y solucin de problemas en proyectos complejos no esuna actividad intuitiva ni una intervencin de emergencia, o hay que intentarque no sea as, lo mximo posible. Decisiones tomadas precipitadamente, anteproblemas mal definidos, sin la informacin relevante y el anlisis y consultasadecuadas, y sin la evaluacin de su impacto sobre el proyecto, suelen conduciral error y minan la confianza del equipo y del cliente en el jefe de proyecto.

El ciclo de toma de decisiones debera responder a la siguiente secuencia deactuacin (figura 5).

Nota

En este subapartado seguimosel manual de Rodrguez, Gar-ca y Lamarca (2007, pgs.171-174).


Figura 5. Secuencia de toma dedecisiones en un proyecto


1)Ladefinicindelproblemaolaoportunidad, es decir, la identificacino reconocimiento de la necesidad, en forma de problema u oportunidad. Estanecesidad resulta del gap o diferencia entre aquello que se hace o pasa (pro-blema) y lo que se planific en su da, y entre aquello que se podra hacer(oportunidad) y lo que se planific en su da.

2)Labsquedayelanlisisdelainformacindisponible. Cualquier tomade decisiones requiere un proceso de bsqueda selectiva de la informacinrelevante que detalle la oportunidad o el problema que hay que resolver. Esbueno que este proceso, para que no consuma excesivos recursos y est enfo-cado, se gue desde una generacin de las hiptesis ms probables (hipothesysdriven), de manera que slo tendremos que buscar aquella informacin quepermita validar o rechazar nuestra hiptesis.

3)Eldesarrollodeescenariosdeevolucinde lasituacin de necesidadpermite analizar cul puede ser la evolucin futura del problema o la oportu-nidad y, por lo tanto, tomar

gestión de proyectos

Documents