Archive for the ‘Comunicaciones’ Category

Aceptando el reto

Jueves, Marzo 19th, 2015

Recientemente iniciamos un proyecto para un cliente estadounidense. Nuestro cliente quería un sitio web en el que se incluyera un componente de donaciones para una asociación civil sin fines de lucro, por lo que el presupuesto era muy ajustado. Adicional a esto, el cliente necesitaba que el sitio estuviera operando para inicios del año, lo que nos dejaba un calendario muy ajustado para terminar. La fecha de entrega no era negociable porque ya se había publicado la fecha del inicio del concurso que recaudaría los fondos y cada día que fuera entregado tarde el sitio representaba una pérdida en el potencial de recaudación.

shutterstock_7861366.jpg

Previo al proyecto

El cliente en EUA de primera instancia buscó compañías en ese país para que le hicieran el trabajo, pero con el presupuesto reducido y, sobre todo con el calendario tan apretado, tres compañías le rechazaron el proyecto. Posteriormente encontró un par de compañías basadas en India que accedieron a hacer el sitio por el presupuesto ofrecido, pero ninguna de las dos compañías ofrecieron terminarlo a tiempo, de hecho, ambas coincidieron en que lo podrían hacer en el doble del tiempo presupuestado.

Finalmente buscaron en México y siendo nosotros socios comerciales en proyectos pasados nos solicitaron la implementación. Revisamos la factibilidad y decidimos abordar el proyecto pero con una metodología ágil en la cual redujéramos algunos costos. La propuesta fue aceptada e iniciamos el proyecto.

Factores de riesgo

Adicional a la metodología ágil, otra estrategia que implementamos para reducir el costo fue conseguir personal externo a nuestra compañía que hiciera el trabajo con un precio por debajo de nuestro propio costo y buscamos personal en entidades socioeconómicas de menor nivel (fuera de la ciudad de Monterrey) y con los conocimientos técnicos para hacer la tarea.

Entrevistamos a algunos individuos y finalmente contratamos a dos de ellos en una ciudad a más de 2,000 kilómetros de distancia.

shutterstock_98130041.jpg

El proyecto involucraba el desarrollo sobre un Sistema Administrador de Contenido (Content Management System o CMS ó por sus siglas en inglés) que nuestro equipo nunca había utilizado y también involucraba la interacción con una entidad para la recepción de donaciones de manera segura, cosa que tampoco habíamos implementado antes.

Todo esto preparaba una atmósfera de riesgo adicional en el proyecto sin embargo decidimos tomar el reto con el afán de dar el servicio y con la expectativa de hacer algo que otros no habían querido hacer.

Las fiestas decembrinas, el fin de año, el equipo de trabajo a distancia, la metodología ágil, el presupuesto cerrado del proyecto, la fecha agresiva de entrega del proyecto y la tecnología que nuestro equipo no dominaba eran riesgos evaluados pero no poco considerables.

La ejecución del proyecto

En las primeras fases todo parecía ir bien hasta que solicité ver físicamente los entregables, empezamos a notar que no estaba todo lo que los externos decían que iban a completar. El líder de los externos empezó a postergar entregables de un sprint a otros posteriores y lo que fuimos recibiendo eran entregables incompletos.

Hicimos la primer presentación del avance al cliente de manera exitosa indicando que postergaríamos algunos de los entregables para una presentación posterior y el cliente aceptó.

Llegaron las festividades decembrinas y por un tiempo no recibimos avances considerables. El equipo externo estaba localizable, pero los entregables no se completaban. Establecimos una estructura de revisiones más cercanas que el equipo externo no pudo cumplir ya que no tenían siquiera una estructura de trabajo formal.

shutterstock_20302609.jpg

En subsecuentes revisiones con el cliente, éste se mostró preocupado por el escaso avance y empezó a cuestionar nuestra capacidad de entrega del producto a tiempo, por lo que me vi forzado a tomar por completo el control del equipo externo aún cuando su líder se resistía a ser administrado.

Iniciamos juntas diarias con el equipo remoto y establecimos metas claras diariamente para ir concluyendo cada uno de los entregables. También concentré al equipo en pocas actividades de alto valor, esto nos permitió ir acabando lo más importante aún que fueran pocos entregables y evitar tener muchos medios avances.

Agregué un equipo de pruebas que no era de ingenieros de pruebas (QA Testers), sino un equipo de desarrolladores de sistemas que empezaron a probar cada uno de los entregables que a su vez el equipo de externos iba produciendo. Esta decisión tenía tres objetivos: 1) reducir el tiempo del ciclo entrega-testing-documentación-remediación-entrega, 2) involucrar a nuestro personal técnico en la solución desarrollada, para que pudiera hacerse cargo de algunas partes del desarrollo del sitio en un momento dado, y 3) para que nuestro equipo apoyara en la remediación de algunos defectos, de tal forma que redujéramos la cantidad de trabajo enviada a los externos para remediación.

Continuamos con las revisiones diarias que a la vuelta de las semanas se volvieron muy cansadas ya que no permitíamos que el equipo se fuera a descansar sin concluir las metas propuestas por ellos mismos en el día. Debido a algunos problemas de actitud que el equipo de externos tenía, las revisiones se volvieron tortuosas, sin embargo para mediados del mes de enero, muy cerca ya de la fecha de entrega, declaramos como terminado todo el sitio y solo quedaron algunas actividades de pruebas y remediación de errores.

Las pruebas finales

shutterstock_56950768.jpgHacia el fin del proyecto invitamos al cliente a entrar al sitio para que validara toda la funcionalidad, el accedió e invitó a tres integrantes de su empresa para probar el sistema. Nosotros les compartimos el acceso a una herramienta para el reporte y seguimiento de los errores encontrados y en ese sistema ellos fueron capturando cada problema encontrado. Nuestro equipo revisaba la lista de problemas encontrados y priorizaba  su atención, asignaba cada problema a un responsable de desarrollo e iba remediando cada problema y probando que hubiera quedando resuelto. De esta manera proporcionamos un entorno muy visual y transparente del avance en la resolución de problemas encontrados.

La entrega

El sitio lo terminamos dos semanas antes de la fecha final de entrega y esas dos últimas semanas el cliente estuvo revisando y reportando problemas mientras nuestro equipo los resolvía. El día previo a la fecha final de entrega, alrededor de las 7:30pm terminamos de corregir todos los problemas y el sitio pudo ser anunciado en la prensa local y las donaciones empezaron a entrar al día siguiente.

Hubo algunos cambios que nos solicitó el cliente conforme iba probando el sistema y conforme veía su desempeño, pero gracias a que involucramos a nuestro equipo pudimos hacer internamente lo solicitado sin recurrir a los externos, a quienes ya habíamos liberado con la intención de no volver a contratarlos más.

Conclusión

Nos quedamos con muchas lecciones aprendidas de este proyecto, pero una de las principales es que necesitamos tomar los retos que se nos presentan, pero con una evaluación adecuada de los riesgos y de nuestra capacidad para afrontarlos. Desde luego aprendimos que debemos combinar el menor número de riesgos, por ejemplo, pudimos experimentar con un grupo de externos con los que no habíamos trabajado antes, pero en un proyecto más holgado.

Nuestro cliente quedó sorprendido por nuestra entrega a tiempo con fechas tan agresivas y un presupuesto tan recortado y gracias a eso ya estamos firmando nuevos proyectos con ellos, pero más holgados y en mejores condiciones presupuestales.

Creo que podemos hablar mucho de lo que hacemos, pero cuando nos dan la oportunidad de demostrarlo eso se convierte en el mejor argumento de ventas para nuestro equipo de trabajo. 

shutterstock_76411899.jpg

Los indicadores de avance del proyecto

Jueves, Febrero 27th, 2014

Hace poco estuve al cargo de varios Gerentes de Proyectos (PMs = Project Managers) con quienes interactuaba frecuentemente para conocer el avance de sus proyectos asignados. Al llegar con uno de los PMs le pregunté “¿cómo va el progreso en las actividades del proyecto?”, y el me platicó por veinte minutos todos los pormenores por los que había cruzado el equipo y abundó en las dificultades del proyecto, me comentó sobre las largas jornadas de trabajo de los integrantes y las peleas internas entre ellos, me habló sobre el pobre desempeño de alguno de los consultores y mucho, mucho más.

1.jpg

Al final de su explicación le volví a preguntar, “y… ¿cómo va el avance del proyecto?”.

Cuando se trata de un proyecto, siempre es necesario tener información para poder evaluar su progreso, pero debemos aprender a obtener y a comunicar la información estrictamente necesaria para lograr ese objetivo.

Después de una sonrisa, el PM me dijo “acabo de decirte como va el proyecto”, y yo le contesté “no, me acabas de platicar algunos pormenores de lo que ha ocurrido desde la última vez que reportaste avances, pero aún no sé si el proyecto va a terminar a tiempo o no, o si tenemos un desempeño del gasto del presupuesto dentro de los límites aceptables. Tampoco me has comentado la probabilidad de ocurrencia de los riesgos que has detectado ni el impacto que tendría si alguno de ellos se materializara. No me has permitido conocer el número de casos de prueba generados, ni aquellos que ya fueron ejecutados y de éstos cuáles han resultado exitosos y cuáles necesitan ser remediados.”

Después de dar seguimiento a múltiples proyectos con clientes de todas dimensiones, he concluido que necesito el mínimo de información objetiva y medible para darme una idea general del avance del proyecto. Una vez habiendo evaluado esa información, entonces sí me interesa conocer los detalles no-duros (subjetivos y desestructurados) más importantes que me permitan apoyar a mis PMs y al equipo de proyecto para que tengan un mejor desempeño y para alcanzar las metas del proyecto. Desde mi perspectiva se requiere un equilibrio entre información dura y no dura para llegar a conclusiones más completas.

Cuando terminé de hablar con mi colega le pregunté cuál era el SPI del proyecto (Schedule Performance Index = Índice de desempeño del cronograma) y recibí un silencio ensordecedor. Así que aprovechando que el siguiente lunes era festivo, llamé al PM, al Líder Técnico y al Líder de Pruebas del Proyecto a una junta a las 9:00am para discutir sobre esos temas. Para aprovechar el tiempo les pedí que trajeran la siguiente información lista para nuestra sesión de trabajo:

* Plan general del proyecto (incluyendo el cronograma).

* Número de horas totales del proyecto (Presupuesto original de horas).

* Número de horas consumidas al día de hoy (Valor actual de horas consumidas).

* Actividades del plan terminadas al 100% y la suma de las horas que representaba ese avance (Valor ganado)

2.jpg

Con esta información pude calcular los indicadores normales de valor ganado como el desvío actual del presupuesto y del calendario (Cost Variance y Schedule Variance respectivamente) y pude calcular algunos pronósticos como el número de horas totales invertidas al terminar el proyecto (EAC = Estimate At Completion) y el número de horas pendientes por trabajar (ETC = Estimate To Complete) si siguiéramos trabajando al mismo ritmo.

En ese momento, todos nos dimos cuenta que el proyecto iba retrasado en tiempo y que el equipo tenía un desempeño del 95%, es decir, que por cada hora trabajada solo el 95% de esa hora estaba siendo empleada en actividades que agregaban valor al progreso del proyecto como estaba definido originalmente.

También nos dimos cuenta de que estábamos gastando el presupuesto del proyecto más rápido de lo planeado y que al ritmo al que íbamos terminaríamos en números rojos al finalizar.

Adicionalmente el cliente nos estaba poniendo una restricción en el calendario, donde necesitaba recibir el sistema que estábamos construyendo a mas tardar en 2 meses incluyendo todos los entregables, y gracias a los indicadores que obtuvimos pudimos ver que eso no iba a ser posible si seguíamos trabajando al ritmo que llevábamos (SPI menos que 1).

Terminamos nuestra reunión interna después de 3 horas y le pregunté al PM acerca de la relación que llevábamos con el cliente a lo que el me contestó que era inmejorable, que estaba muy contento con el trabajo del equipo y que ya estaba viendo la manera de entregarnos otros requerimientos para futuros sistemas.

En mi opinión, hemos hecho del proceso una meta, siendo que la meta es el resultado del proyecto. El proceso es importante desde luego porque determina la recurrencia en proyectos con el mismo cliente (nuevos negocios), pero lo que debe recomendarnos es nuestra capacidad para dar resultados. He leído en diversos artículos que la administración de proyectos es tanto una ciencia como un arte y estoy de acuerdo con eso, el problema es que a veces tendemos mucho hacia el arte o hacia la ciencia de manera exclusiva y desequilibrada y perdemos el beneficio del extremo descuidado.

 3.jpg

En el caso del proyecto que les platico, le pedí al PM una revisión semanal de algunos de estos indicadores y le generé una plantilla en una hoja de cálculo para que el pudiera generar esta información con facilidad. El PM dedicó su creatividad y la del equipo a buscar maneras de revertir el retraso y aumentar la productividad para cumplir con la restricción de cronograma que teníamos. Tuvimos que agregar un apoyo externo para poder terminar a tiempo, lo que incrementó el presupuesto del proyecto, pero afortunadamente esto lo comunicamos con anticipación y no generó un problema con el cliente.

Soy un creyente de que las relaciones con los clientes deben cuidarse, pero también pienso que la relación es el camino y no la meta, y para alcanzar metas con calidad necesitamos medir, corregir y entregar.

Administramos cosas, lideramos personas

Miércoles, Septiembre 4th, 2013

No es posible administrar a una persona, porque le reduciríamos al nivel de una cosa. La palabra correcta para decir que alcanzaremos los objetivos a través de una persona es “liderar”. Aclarado lo anterior podemos darnos cuenta que lograr los objetivos a través de la gente no es un asunto de conocimientos en administración, tecnología o negocios, sino de liderazgo, y que el liderazgo no es un asunto de efectividad, sino de eficacia. Logramos muchas cosas siendo efectivos, pero logramos los objetivos correctos siendo eficaces.

diplomados-mba-low.jpg

En una ocasión, mientras trabajaba en una empresa internacional, me tocó trabajar con un equipo que tenía integrantes de México, Estados Unidos e India. Yo era Administrador de Proyectos e invertía mucho tiempo en comunicación en todas direcciones: tenía reuniones de avance con mi equipo, creaba reportes de avance para la alta gerencia, negociaba y verificaba que nada obstaculizara el progreso del proyecto.

El proyecto iba bien, es decir, con los retos normales que conlleva un proyecto de grandes dimensiones, pero no tardé para darme cuenta de que el reto mayor no estaba en construir entregables en tiempo y costo, sino en el terreno del liderazgo de aquel equipo.

Teníamos una organización matricial. Los desarrolladores de software tenían un gerente funcional, los ingenieros de pruebas tenían a un jefe funcional y los arquitectos también tenían su propio jefe funcional. Por mi cuenta, yo tenía un equipo con recursos de las tres áreas: desarrolladores, testers y arquitectos, y para efectos de ese proyecto yo era su jefe.

Esta estructura trajo muchos beneficios, pero también muchos retos.

Una estructura matricial en la que los recursos dependen “verticalmente” de gerentes de área especializados en una función y “horizontalmente” dependen de administradores de proyectos, es una estructura flexible que requiere de mucha madurez por parte de todos sus miembros.

Algunos puntos “complicados” que he notado cuando administras proyectos en este tipo de estructuras son los siguientes:

1) Muchos jefes, poco compromiso. Cuando la gente del equipo no está acostumbrada a trabajar en una organización matricial, en ocasiones no puede ver con seriedad que su jefe es el Administrador de Proyectos en turno. Esta gente con frecuencia acude con su gerente funcional para validar si realmente tiene que hacer esto o aquello y no deja de reportarle su avance pasando por alto al administrador del proyecto. Esto complica las cosas, porque cuando hay mas de una persona a quien reportarle, el compromiso para terminar las tareas disminuye. Durante el período de vida del proyecto, los integrantes del equipo le deben reportar absolutamente todo al Administrador del Proyecto. Cuando hay algún problema con alguno de los recursos humanos, es responsabilidad del Administrador del Proyecto reportar dicho problema al gerente funcional para que éste resuelva a favor del proyecto.

2) Papá vs. Mamá. Cuando “papá” no me da permiso, corro con “mamá” y le pido permiso. Así es como muchos individuos se comportan en un esquema matricial. Cuando el Líder del Proyecto les niega algo, “corren” con su gerente funcional y tratan de conseguir el permiso. Si un gerente reacciona a favor del individuo conflictivo, la situación se torna aún peor. Se requiere mucha madurez para trabajar en un esquema matricial. El responsable de los recursos durante el proyecto es el Administrador del Proyecto, los demás niveles deben respetar esa figura de autoridad.

3) El problema de las culturas. Una persona en USA se comporta muy diferente a una de India y ésta a una de México. Cuando algunas culturas dan más libertades, otras son mas restrictivas, liderar gente de dos o más culturas siempre trae complicaciones naturales. Como Administradores de Proyecto debemos establecer un estándar de trato a las personas que faculte la igualdad pero que se adapte naturalmente a la cultura de cada país.

success.jpg Al inicio de este post hablé de liderazgo y es exactamente eso lo que se requiere para guiar a un grupo con diferentes culturas y diferentes trasfondos. Si bien la gente es lo mas valioso dentro de un proyecto, también he notado que es la gente la que provoca algunos desaciertos e incluso el fracaso del proyecto.

Liderazgo es adoptar una posición fuerte dentro del proyecto. Por favor no me malinterpreten, cuando digo “posición fuerte” no me refiero a ser el ogro o el “látigo” del proyecto, más bien me refiero a la figura que da dirección, que da certeza, que pone los engranes a moverse, que aconseja, que cuida a los recursos y que da esperanza de que todo en el proyecto va a salir bien. Ser un Líder de Proyectos es adoptar una postura “paternal/maternal” dentro del proyecto. Debes ser la persona a la cual acudir cuando algo sucede dentro de la “familia” o de sus objetivos. Debes dirimir disputas y encontrar las respuestas para que todo siga avanzando. 

Una organización matricial requiere de toda la madurez que se pueda tener por parte de los integrantes del equipo y de los gerentes funcionales, pero si esa madurez no existe, es responsabilidad del Administrador del Proyecto proveer un ambiente sano en el cual los integrantes se desarrollen y cumplan los objetivos del proyecto.

Fernando Valdez

La generación Y dentro de los proyectos

Miércoles, Abril 17th, 2013

Ya hace tiempo que quiero hablar acerca de la nueva generación de empleados, aquellos que pertenecen a la llamada “Generación Y”, y pensé que éste sería un buen foro para comentar acerca de los futuros administradores de proyectos y del reto y las oportunidades que representa su presencia en nuestra profesión.

1w.jpgPrimero quisiera intentar definir quiénes son aquellos que pertenecen a la generación Y. Dije “intentar” porque en realidad no existe una definición que acote con fechas exactas cuando empieza y termina esta generación, pero es comúnmente aceptado decir que los individuos nacidos entre 1980 y el año 2000 son la generación Y. Estos son hijos de los considerados miembros de la generación X. La generación X son aquellos individuos nacidos entre 1968 y 1979 y que a su vez son hijos de aquellos conocidos como la generación de los “baby boomers”.

Sin ánimo de entrar en detalles muy lejanos a la administración de proyectos, quiero destacar algunas características del comportamiento de la generación Y. De acuerdo con diferentes estudiosos del comportamiento humano y muy en concreto de acuerdo con el Dr. Julio A. Fonseca en su participación en la 9na conferencia anual del College Board, la generación Y “se distingue por una actitud desafiante y retadora… lo cuestionan todo, no quieren leer y sus destrezas de escritura son malas… no piden permiso, ellos solo informan… no temen expresar su estado de ánimo y su principal interés no es el grupo, sino ellos mismos”. Estos comportamientos son presumiblemente motivados por la cantidad de información que ellos poseen y que puesta en sus manos les permiten retar a los mayores por tener más conocimientos y de calidad más actual.

Por otro lado, la generación Y ha desarrollado una mayor creatividad. Mientras que los baby boomers y la generación X se centran más en la lógica, la generación Y ha desarrollado un pensamiento creativo que le permite ofrecer soluciones diferentes a los problemas que se nos presentan.

Hoy en día ya empezamos a ver a la generación Y encabezando equipos de trabajo. Líderes de proyecto dinámicos y altamente sociables, que no están en un solo lugar y se adaptan a comunicaciones impersonales. Mientras las generaciones anteriores querían oficinas y definir un protocolo para trabajar todo el mes, esta generación de líderes de proyecto abrazan el cambio y saben que al final de una junta pueden haber cambios sustanciales en lo acordado. Están acostumbrados a colaborar dinámicamente y a la iniciativa de todos los involucrados.2w.jpg

Una estrategia para alcanzar los objetivos de la empresa es potencializar a sus empleados para obtener lo mejor de ellos. Considera los siguientes puntos cuando trabajes con personas de la generación Y:1. Crea un ambiente sin muchas jerarquías. Los miembros de las generaciones anteriores (baby boomers y gen X) tendemos a ser jerárquicos y a pensar en términos de “lo que dijo el jefe”. Si deseas conservar miembros de la generación Y en tu equipo de trabajo, mantén una estructura plana en la que ellos sean parte importante de la colaboración y construcción de beneficios para la compañía.

2. Capacita con ejemplos. A la generación Y le interesan las historias y no tanto la teoría sobre cómo hacer las cosas. Platícales experiencias propias, lecciones aprendidas y añade dramatismo a las conclusiones, eso los mantendrá motivados y con ánimos de hacer su propia historia dentro de la compañía.

3. Dado que la generación Y es dinámica y ha aceptado como normal la comunicación impersonal, facilítales ese tipo de comunicación. No importa que estén dentro del mismo espacio físico, la generación Y disfruta comunicarse por medio de mensajes de texto en el teléfono, inbox, mensajeros, etc. Incorpora ese nivel de digitalización en las comunicaciones del equipo aún y cuando a ti te parezca un medio informal, recuerda, ellos están concentrados en el contenido, no en los medios por los que les llega dicho contenido.

4. No pongas a la generación Y a aprenderse un manual de usuario y no esperes que, aun teniéndolo frente a ellos, vayan a optar por abrirlo antes que saltar y hacer una pregunta. La generación Y no busca teoría, busca experiencias. Es más común ver a la generación Y buscando en medios que nosotros consideramos informales como lo son los blogs y listas de discusión, que abriendo un libro o un diccionario. Si llegaran a buscar alguna definición, ellos prefieren la Wikipedia que un diccionario. La generación Y “googlea” sus dudas.3w.jpg

5. Si es posible, cambia continuamente de rol a los miembros de la generación Y. Nosotros (los baby boomers y la generación X) creemos en la especialización, pero esta es la receta para desmotivar a la generación Y. Aún y cuando también la generación Y ha logrado muy exitosamente dominar aspectos muy específicos de su profesión, ellos no quieren estar quietos y especializarlos es exactamente eso.

No cabe duda de que tenemos un reto delante de nosotros. Hoy en día los baby boomers ocupan puestos directivos en nuestras empresas mientras la generación X ha tomado muchos puestos de gerencia alta e intermedia, sin embargo la generación Y ha llegado, ascendiendo cada vez más alto en los organigramas y su presencia está cambiando la forma en que las empresas administran sus proyectos.

Aprovechemos esta nueva fuerza laboral. Ajustemos nuestros planes de comunicación para que sean más efectivos y para que alcancemos los objetivos del proyecto que, a final de cuentas, es para lo que somos líderes de proyectos.

Fernando Valdez

Control de las emociones de un Líder de Proyectos

Martes, Junio 5th, 2012

business-english.jpgParece que está de moda en el mundo de la administración de proyectos hablar de las habilidades suaves o “soft skills” y esto pudiera ser una respuesta natural al hecho de que por mucho tiempo nos enfocamos a las herramientas y técnicas “duras” como lo es el control del cronograma, el aseguramiento de la calidad, la administración de valor ganado, la evaluación de proyectos por medio de técnicas como el valor presente neto (VPN) y la tasa interna de retorno (TIR), etc., de tal forma que descuidamos el lado humano de la administración de proyectos.

En mi experiencia diaria me he encontrado libros, anuncios de conferencias, ensayos y artículos que se publican y que están llenos de temas relacionados con el manejo de técnicas sobre como escuchar atentamente, cómo ser empático con los miembros del equipo, cómo desarrollar las habilidades para resolver conflictos laborales, etc.

Si tú eres como yo y has tomado todos los cursos de habilidades interpersonales que ofrece el mercado (estoy bromeando, desde luego), entonces probablemente querrás internarte más en el mundo de las herramientas y técnicas de administración de proyectos; pero esta entrada del blog, quisiera dedicarla a comentar algunas experiencias que tuve en el área de las relaciones interpersonales dentro de los proyectos que administré.

Hubo un tiempo hace alrededor de 12 años cuando se escuchó mucho hablar acerca de la inteligencia emocional. Recuerdo haber visto estantes llenos de libros que trataban ese tema en diferentes variedades. La inteligencia emocional, de acuerdo con Daniel Goleman, esta definida como “la capacidad para reconocer sentimientos propios y ajenos, y la habilidad para manejarlos”.

Recuerdo haber asistido a una conferencia en el Tecnológico de Monterrey a la que llamaron “Manejo inteligente de las emociones”, en la que nos enseñaron que cada individuo es responsable por sus propias emociones y que si por algún motivo alguien tiene que lidiar con las suyas, los demás no pueden hacer demasiado para ayudarle con esa tarea, ya que es algo muy personal. A mí me sonó egoísta en un principio, pero tenía sentido, ya que no puedes meterte dentro de esa persona y controlar sus emociones, sólo puedes enseñarle a canalizarlas. Cada persona debe hacerse responsable por sus propias emociones y, desde luego, por las consecuencias del buen o mal manejo de las mismas.

En el rol de líder de proyectos lidiamos a diario con las emociones de los demás y muchas veces, esto incluye también enfrentarnos con sus consecuencias. Un manejo responsable de las emociones por parte de cada miembro del equipo mantiene el ambiente libre de política (o lo que en México comúnmente llamamos ‘grilla’) y la comunicación permanece fluida.

Aún cuando es un hecho que las dificultades se acrecientan de manera proporcional con el tamaño del equipo, en esta ocasión quiero hablar de las emociones del líder del proyecto porque sabemso bien que un miembro problemático puede trastocar algunos aspectos del proyecto. Sin embargo, cuando el problemático es el líder, entonces todo el proyecto se ve afectado negativamente.

Permítanme enumerar algunas recomendaciones al respecto, todas con base en mis experiencias anteriores.

1. Considero que un líder de proyecto debe guardar sus emociones para sí mismo y nunca externarlas en público.

Esto tiene un doble propósito y, desde luego, el más evidente es el propósito de mantener el profesionalismo. Pero dado que el líder de proyecto con mucha frecuencia está en contacto con información confidencial, el propósito secundario de guardar sus emociones sería el mantener fuera del alcance del equipo dicha información para evitar problemas.

En una ocasión nos avisaron que al terminar nuestros proyectos, tendríamos que despedir a tres miembros de los equipos de un compañero líder de proyecto y de quien esto escribe. Mi compañero se molestó e intentó conservar su equipo completo, pero las órdenes ya estaban dadas. Mi compañero regresó a su lugar de trabajo visiblemente molesto y losservices-consultancy.jpg miembros de su equipo no tardaron en preguntarle qué le pasaba. El eludió algunas preguntas de su grupo, pero al calor de su enojo externó los motivos de su molestia con uno de los miembros de su equipo. Esta persona encontró la ocasión perfecta para “pasar la voz” y los miembros del equipo que iban a ser liberados empezaron a buscar otras oportunidades de empleo. Lamentablemente, esa información sensible también corrió entre los integrantes de mi equipo. Como es obvio suponer, los proyectos se entregaron tarde y los empleados que iban a ser liberados se fueron de la empresa, abandonando el proyecto antes de su cierre.

Me queda claro que un despido es desagradable, pero cuando pertenecemos a una organización debemos proteger los intereses de esa organización. Las emociones de mi compañero líder de proyecto afloraron dando una conclusión con impacto negativo para ambos, su proyecto y el mío. Un líder de proyectos maneja información confidencial y debe asegurarse de que un arrebato de ira o decepción no le haga pasar una mala jugada a la organización completa.

2. Un líder de proyecto necesita mantenerse fuera de la crítica, no debe criticar ni alimentar la crítica entre los miembros de su equipo.

Si hay algún miembro de su equipo con bajo desempeño, el líder de proyecto debe dirigirse a ese miembro de su equipo, de manera inmediata y respetuosa, para tratar de ayudarlo para que este tenga un mejor desempeño en el corto plazo.

En una ocasión conocí a un jefe que para llamarle la atención a un miembro del equipo llamaba a todo el departamento a junta y los regañaba a todos por igual. Cuando uno o dos de los miembros de su departamento le preguntaban quién estaba equivocándose, este jefe les decía y además les platicaba todos los errores que ese compañero cometía. Esto provocaba que los demás miembros del equipo perdieran el respeto que tenían por aquel compañero con problemas de desempeño y, a la vez, provocaba desconfianza del propio jefe, ya que si había hablado mal de uno, bien podría hablar mal de los demás.

Esto también provocó que aquellos compañeros que habían oído al jefe hablar mal de uno de ellos, quisieran agradarlo en todo lo que hacían, cohartando así su creatividad, su capacidad de improvisación y su prerrogativa de cometer errores como cualquier ser humano, lo que generaba una tensión innecesaria. Un líder de proyecto necesita controlar su deseo por criticar.

3. Un líder de proyectos necesita controlar sus ímpetus y mostrarse mentor de sus compañeros.

En una ocasión tuve a un miembro de mi departamento que tenía bajo desempeño, así que llamé al individuo en cuestión y a su líder de proyecto y les expliqué que necesitábamos mejorar el desempeño y, por lo tanto, tomamos control de sus prioridades.

Le dimos dirección en las tareas que necesitábamos que completara e indicamos el nivel de calidad que deseábamos manejar en cada entregable. En el transcurso de la plática el líder de proyecto se mostraba muy inquieto. Cuando yo le daba la palabra, este la utilizaba de manera agresiva, mostrando su desesperación por obtener los resultados de parte del compañero con bajo desempeño. Frases como: “tú necesitas hacer…”, “yo necesito que tu resuelvas…” y “cuando te digan …, tu tienes que hacer…” era lo único que salía de su boca.

estres.jpgNormalmente, yo parto del supuesto de que si alguien no está teniendo el desempeño esperado, es porque a) el compañero no sabe cuales son nuestras expectativas, o b) desconoce como hacer las tareas. Si una vez que se le comunican las expectativas y que se le enseña a elaborar los entregables, el desempeño sigue sin ser el esperado entonces se puede recurrir a reubicarlo o a sacarlo de la compañía. Sin embargo, en el caso citado arriba, el líder de proyecto quería obtener el producto con la mayor premura posible y así se acordó que fuera, aún cuando yo tenía mis reservas al respecto.

Después de una semana de revisiones diarias de progreso, el empleado empezó a cumplir con las expectativas que teníamos de él. De pronto todo empezó a arreglarse. Incluso el empleado en cuestión me confesó que pensaba que las cosas se hacían diferente a como se las habíamos explicado y que por eso lo hacía mal creyendo que lo estaba haciendo bien.

Dado que mi responsabilidad era de más alto nivel, dejé esta reunión de entrenamiento en manos del líder de proyecto quien la hizo a un lado pensando que era una pérdida de tiempo. A los pocos días el empleado volvió a mostrar un bajo desempeño y tuvimos que deshacernos de él. Independientemente de la decisión que se tomó, considero que un líder de proyecto debe ser exigente y buscar la obtención de los resultados, pero debe hacerlo por medios inteligentes y no mediante el empleo de la fuerza bruta. Un líder de proyectos es un mentor nato y debe cumplir con esa responsabilidad al margen de sus emociones. Siempre.

En resumen: un líder de proyecto debe ser inteligente al manejar sus emociones. Nadie puede hacerlas a un lado, están allí y es otro aspecto que necesitamos aprender a administrar. Muchas veces las emociones nos facultan para alcanzar objetivos que, sin ellas, no hubiésemos alcanzado. Pero la cuestión fundamental es que se trata de canalizarlas de manera adecuada, para que así éstas trabajen para nosotros y no metan en problemas a nuestro proyecto y a nuestra organización.

Quiero mencionar que tampoco se trata de ser fríos y calculadores, y no demostrar emoción alguna a la gente que nos importa. Se trata más bien de mantener un equilibrio sano entre quienes somos y lo que deseamos comunicar.

Como conclusión quisiera resumir el tema en una recomendación: considero que un líder de proyectos siempre debe ser una persona madura. Cuando hablo de madurez, desde luego que no estoy haciendo referencia a la edad cronológica de la persona, ya que todos sabemos pr más de uan experiencia directa que la madurez no llega con la edad.hablo de un individuo que se conoce a sí mismo, sabe lo que necesita hacer y cómo expresarlo a su equipo para que este le reporte los resultados esperados.

Sobra decir que una persona inmadura reflejará comportamientos muy parecidos a los descritos en las situaciones anteriores. En cambio, cualquier persona madura estará satisfecha con lo que realiza todos los días y, aún cuando en su vida personal no tenga el equilibrio que debiera, es una persona que sabe lidiar con eso en lo privado y que está capacitada para encontrarles soluciones maduras, para así no traer sus problemas personales al trabajo y, menos aún, hacer que afecten su relación con su equipo de proyecto y su desempeño.

La productividad de un líder

Miércoles, Febrero 29th, 2012

Existe una injustificada discusión entre lo que tendría que hacer el líder del proyecto y lo que realmente está haciendo y dicha discusión tiene que ver con el nivel de involucramiento que éste debería tener con los entregables técnicos del proyecto. Para salir pronto de dudas, el líder del proyecto debería estar más involucrado con el funcionamiento del equipo, que con la fabricación de los entregables. Algunos autores dicen que un administrador de proyectos nunca debería encontrarse en la ruta crítica del proyecto y esto es porque sus actividades, de naturaleza principalmente administrativas, pueden retrasar el trabajo de los demás compañeros. Esto no quiere decir que un líder de proyectos no debería participar en la construcción de entregables de un proyecto, pero si advierte que hay diferencias entre las actividades de un miembro del equipo y su líder.

estres-laboral.jpgComo decimos en México: “ni tanto que queme al santo, ni tanto que no lo alumbre”. Como PMs necesitamos documentar, necesitamos reportar avances, necesitamos documentar riesgos y actualizar el registro de problemas, necesitamos actualizar el cronograma y volver a empezar otra vez. Sin embargo, además de todo esto, necesitamos ser productivos. Necesitamos entregar resultados. Los resultados que un PM entrega no sólo son documentos escritos, sino resultados a través del equipo del proyecto. Que se haga lo que está planeado hacerse, que se entregue lo que se prometió con el nivel de calidad que se esperaba. Que la gente haga lo que tiene que hacer.

Hace ya muchos años, cuando formaba parte de Toastmasters, una organización internacional cuyos miembros aprenden y practican técnicas de comunicación en público y de liderazgo, tuve la oportunidad de formar parte de la mesa directiva que se integraba de siete personas: un presidente, un vicepresidente educativo, un vicepresidente de membresías y otros cuatro individuos con diferentes funciones. Yo asumí la presidencia del club y en la toma de protesta, el presidente saliente me dijo unas palabras que tienen mucho sentido cuando se trata de dirigir equipos de trabajo. El presidente saliente me dijo: “este es el momento en el que vas a tener que hacer todo lo que se tenga que hacer en el club, pero a través de la gente”. Más adelante pude observar como muchos presidentes de otros clubes empezaban muy bien, pero terminaban solos, haciendo mediocremente todo el trabajo que tendrían que hacer siete personas, pero ellos solos o con uno o dos ayudantes informales. Pero una posición de liderazgo no supone que el líder tenga que hacerlo todo el solo, sino que tiene que motivar, coordinar, dirigir y administrar para que cada miembro del equipo haga lo que le corresponde.

Durante mi gestión como presidente del club usé esa frase como un termómetro de mi liderazgo: si me encontraba haciendo lo que se suponía que otros tendrían que estar haciendo, entonces no estaba siendo el líder que debería ser, e inmediatamente empezaba a buscar las deficiencias en mi desempeño. Debo confesar que muchas de las deficiencias que encontré en mpi mismo no tenían que ver tanto con mis capacidades técnicas como con mi carácter o falta del mismo.

En mi trabajo como líder de proyecto también cometí ese error. Hace como quince años trabajaba con un equipo muy pequeño en el que tenía un practicante (estudiante de la carrera de ingeniería en sistemas haciendo prácticas profesionales) desarrollando una parte del sistema que teníamos que entregar. A la una de la tarde estábamos por salir a comer cuando me anunció el practicante que no podía terminar lo que íbamos a presentar a las tres de la tarde, justo después de comer. Al mismo tiempo se acercó otro desarrollador y me dijo que tampoco podía estar listo para la presentación. Me enojé mucho y empecé a cuestionar su desempeño. Los interrogué para saber dónde estaban encontrando las mayores dificultades y una vez que encontramos el problema me avoqué a resolverlo con mis propias manos. Les dije “Parense junto a mi para que vean cómo se hacen las cosas”. Los mantuve a cada uno viendo sobre mis hombros hasta que, diez minutos antes de la presentación, terminé todo el trabajo, probamos y todo funcionó correctamente.

Me levanté y les dije “no merecen estar en la junta de presentación de avances” y acudí a la junta yo solo. Afortunadamente todo salió bien: el usuario quedó complacido y mi coraje ya había desaparecido. Esa noche estuve reflexionando. Desde luego estaba orgulloso por mi desempeño técnico porque había resuelto en tiempo récord lo que dos desarrolladores no habían podido resolver, pero no estaba tan orgulloso por mi desempeño como líder. Por alguna razón los desarrolladores no pudieron cumplir con su tarea y yo no me enfoqué en darles la confianza y la oportunidad para ventilar eso. Claro que el tiempo estaba encima y no podía sentarme a hacerle al psicólogo mientras teníamos que entregar un resultado, pero también es cierto que no había motivado a esos muchachos últimamente ni había dado la oportunidad para discutir dificultades acerca de sus asignaciones.

Ese día terminé con una sensación de vacío que estaba tratando de llenar con falsos sentimientos de orgullo acerca de mi desempeño técnico. El vacío tenía que ver con una falta de liderazgo. Entregamos a tiempo, pero la relación con mis desarrolladores quedó desgastada, los humillé y no les ayudé en lo absoluto. Creía que ellos deberían aprender con la valiente hazaña que yo había hecho, pero estaba muy equivocado. Ese día me prometí no volver a meter las manos en el trabajo de otro colaborador, sino apoyarlo hasta que se alcanzara el objetivo aun que eso tomara más tiempo. Esto me obligaría a supervisar frecuentemente, a motivar, a involucrarme auténticamente. En muchas ocasiones posteriores los muchachos se acercaban e insinuaban que necesitaban el tipo de “ayuda” que les habría dado en el pasado (hacerlos a un lado y hacer la programación yo mismo), pero siempre les ofrecía un tiempo para hacer preguntas que los ayudaran a salir del ciclo mental en el que habían caído, hasta que empezaban a encontrar ellos mismos la solución. Al acercarme más a mi equipo pude entender mejor cuáles eran sus fortalezas y cuales sus debilidades y me enfoqué a ayudarles a superarlas con anticipación.3d-women-arrow-011-300×300.jpg

En una ocasión asigné un trabajo a una practicante y al poco tiempo se acercó y me dijo que no podía hacer el trabajo. La escuché y le di algunas ideas de como podía resolverlo y se fue contenta a intentarlo. Regresó unas horas después diciendo “ya lo intenté y no se puede”. Le pregunté qué es lo que esperaba que yo hiciera y ella me dijo “pues que se lo asignes a alguien más y me des a mí algo más fácil” a lo que yo le contesté “aquí no estamos en la escuela en donde muchas veces se premia el esfuerzo, éste es el trabajo y el trabajo se hace o no se hace, aquí no hay calificaciones de siete  u ocho, aquí es diferente”. Después le di otros consejos de cómo podría resolver el problema y se retiró muy pensativa. Mas adelante regresó diciéndome que mi sugerencia no funcionó, pero que intentó otras muchas cosas hasta que lo logró. Yo revisé el producto y realmente el problema estaba resuelto. Me sentí muy satisfecho por no haberle resuelto la situación; ella entendió que yo estaba para ayudarle, no para resolverle sus problemas, entendió que ella era responsable por dar un resultado, ella entendió que se le pagaba un sueldo por los resultados que diera y no por intentarlo. Ella estaba motivada y yo me estaba convirtiendo en el líder de proyecto que creía que debía ser.

La productividad no tiene que ser vista como la cantidad de cosas que haces, sino como los resultados que provocas para la compañía. Los resultados de un líder de un proyecto deberían ser medidos en su capacidad por hacer que los demás den resultados, por el nivel de liderazgo que demuestras, por tu capacidad de hacer que los demás hagan lo correcto, en el tiempo adecuado y con la calidad que se requiere.

Desde luego que los reportes de avance son necesarios, pero el liderazgo es mucho mas que eso. A veces hay que ser psicólogo, a veces adivino y, si el equipo lo necesita, a veces hay que “arriesgarse” a ser un amigo para ellos.

Por Fernando Valdez

Historias de contratación de personal para los proyectos

Miércoles, Noviembre 16th, 2011

268992_illustration.jpgAunque entiendo que este es un espacio de líderes de proyecto, también entiendo que en varios países nuestros líderes de proyectos desarrollan funciones de manejo de personal como contratación, autorización de vacaciones, etc. Por eso quisiera compartir con ustedes experiencias y lecciones aprendidas con respecto al reclutamiento, la selección y administración del personal.

El caso de las mentiras en la entrevista

Hace ya varios años yo trabajaba en el departamento de desarrollo de sistemas de un banco y un compañero al que llamaré Juan, me dijo que había acudido a una entrevista de trabajo, pero que no tenía el perfil requerido por el puesto. Juan se lamentaba por los beneficios que se le habían ido de las manos por no cumplir con el perfil. Poco después Juan me comentó que había ido a otra compañía a ofrecer sus servicios y que en esta ocasión si había tenido éxito. Cuando le pregunté de qué se trataba el trabajo me explicó que tendría que administrar una plataforma IBM así como operar parcialmente la base de datos (DB2) y desarrollar algunos scripts para obtener información de la misma. Me pareció extraño que Juan hubiera sido aceptado para ese puesto porque yo lo conocía y sabía que el no tenía esa experiencia, entonces le pregunté “oye, y ¿sabes hacer todo eso?” y el me contestó “no, de hecho estoy un poco preocupado. No sé como vayan a reaccionar cuando se enteren que les eché mentiras en la entrevista…”

Juan tenía un grave problema de ética, pero el problema mayor radicaba en aquellos que lo seleccionaron para ingresar a la compañía sin comprobar de alguna forma que el candidato tuviera las habilidades necesarias para desempeñar su puesto. Necesitamos ser muy cautelosos al entrevistar personal, sin caer en el extremo de ser groseros con el mismo. Por cierto, Juan entró a trabajar en aquella compañía y lo despidieron en dos semanas, después de ese fracaso no acumuló mucho currículum en otras compañías formales de la zona.

El caso de las promesas incumplidas

Apliqué para ingresar a trabajar en una empresa y fui seleccionado como un candidato factible. En el paquete de prestaciones me prometieron que me darían un bono anual equivalente al 10% de mi sueldo anual liquidable en el mes de noviembre de cada año. Hice mis cuentas e incluí este bono como uno de los ingresos fijos anuales y dado que me convenía, decidí aceptar la oferta y cambiarme de trabajo. Poco antes de ingresar a la compañía me llamaron para firmar un acuerdo de contratación, así que fui y cuando llegué el reclutador dijo que sólo se trataba de un formalismo y que lo que decía el acuerdo era exactamente lo que habíamos discutido antes.

El reclutador se mostró muy hablador mientras yo revisaba los papeles, así que no puse toda mi atención en lo que estaba a punto de firmar. Finalmente firmé y me retiré. Llegó mi primer día de trabajo y acudí a la empresa donde por un lapso de tres meses hice mis mejores esfuerzos por sobresalir y cumplir mi parte del trato. En ese momento llegó el tiempo de la liquidación de bonos y me surgió la duda de si me pagarían un proporcional de aquel bono y fue cuando el gerente de recursos humanos me visitó y me pidió hablar aparte. En su mano traía algunos papeles y enseñándomelos me preguntó ‘¿este es el documento que firmaste tú hace unos meses?”, yo asentí y entonces me dijo “éste es tu contrato y si revisas bien, en este documento no aparece un bono anual”. Yo le expliqué lo que había ocurrido y me dijo que no podía hacer nada al respecto.

img_como_tengo_que_hacer_el_contrato_de_un_servicio_7432_orig.jpg Fue un error de mi parte haber firmado el documento dejándome distraer por aquel reclutador con poca ética, sin embargo una compañía debe cuidar estos detalles ya que impactan directamente en la credibilidad general de la compañía y de sus empleados. Algunos reclutadores son meros vendedores (sin menospreciar la valiosa labor de éstos) que buscan una comisión por el trato pactado, pero tanto en el caso de los reclutadores como de los vendedores debe haber ética para no comprometer a la compañía a ofrecer lo que no están dispuestos a cumplir. Por cierto, me enteré de que el reclutador que me contrató creó una base de datos con información de nuestros empleados, renunció y se la llevó. Poco tiempo después cada persona que laboraba en mi departamento recibió una llamada de este reclutador invitándolos a dejar nuestra compañía para ingresar a otra.

Las referencias laborales ignoradas

Un miembro problemático de mi equipo al que llamaré Pedro había estado criticando la forma en que administrábamos la organización y “la gota que derramó el vaso” fue su actitud visiblemente grosera durante una reunión de departamento. Terminando nuestra junta le pedí un momento a solas para conversar sobre su actitud y el me comentó todo lo que pensaba.

Pocos días después me reuní con gerentes y directores del departamento porque se estaba presentando una dificultad financiera y necesitábamos dar de baja a un miembro del equipo. Después de revisar el desempeño de cada uno de los miembros determinamos que quien tenía el desempeño mas bajo era Pedro. Llegado el día dimos de baja a Pedro y dejó de ser un problema.

Poco después una reclutadora de nuestra empresa me contactó para preguntarme si Pedro había trabajado conmigo ya que necesitaba referencias para llenar una posición para la que Pedro parecía bien calificado. Yo le comenté acerca de su desempeño y de su actitud y dejé que la reclutadora tomara la mejor decisión, ella se mostró decepcionada al escucharme ya que pensaba que había encontrado al candidato ideal. Poco después alguien de mi departamento me comentó que se había encontrado con Pedro quien había ingresado a la compañía en la posición por la que me solicitaron referencias.

Mi unidad de negocio no se vio afectada por tal contratación, sin embargo estoy seguro que la compañía sufrirá por individuos como Pedro dentro de la ella gracias a un consejo no escuchado. La reclutadora cumplió con su “cuota de contratación” y echó el problema a otro lado. Ese era un problema ya resuelto que resultó ser un nuevo problema para la compañía.

Información equivocada de la fuente equivocada

En una ocasión abrimos una posición nueva en la empresa y, después de evaluar muchos candidatos, encontramos uno con todas las características que necesitábamos. Cuando le hicimos la oferta económica se mostró interesado. Más adelante la reclutadora me informó que el candidato a quien llamaré Javier, había aceptado nuestra oferta.

Pasó un par de meses y un día Javier me pidió hablar en privado. Me dijo que en su proceso de reclutamiento había habido un mal entendido, dijo que la reclutadora le había informado mal acerca del porcentaje de impuestos que le iban a quitar y que su sueldo neto estaba muy por debajo de lo que el esperaba. Yo le pregunté a Javier qué dato le había dado la reclutadora y me dijo que le había dicho que le quitarían sólo el 5% de su sueldo por concepto de Impuesto Sobre la Renta (ISR). Le pregunté si antes había tenido un trabajo de planta y me comentó que no, de tal forma que le expliqué que cuando se trabajaba de planta el porcentaje de descuento por concepto de impuestos no podía ser menor al 30%, y que desde luego la reclutadora no era una autoridad para proporcionar esa información. Le dije que lamentaba la confusión y que iba a ver la posibilidad de hacer algo al respecto. Mis superiores coincidieron en que no había presupuesto para incrementos y que la breve permanencia de Javier no ayudaba para evaluar si valía la pena aumentarle el sueldo. Javier, se desmotivó al escuchar la noticia y al poco tiempo se retiró de la compañía.

smarter-procurement.jpg Perdimos un buen elemento y gastamos tiempo y dinero en capacitación y en todos los esfuerzos de reclutamiento y selección de personal, sólo porque la persona equivocada dio información equivocada sin tener autoridad para darla.

La autorización no autorizada

En una ocasión abrimos una posición para la que recibimos muchos candidatos. Después de un par de entrevistas con diferentes personas decidimos avanzar en el proceso con uno de los ellos y, de acuerdo con el proceso de reclutamiento, solicité que se elaborara una propuesta económica.

El procedimiento dictaba que una vez hecha la propuesta, ésta me debía ser enviada para conseguir las autorizaciones y poder extenderla al candidato o rechazarla y volver a elaborarla. Sin embargo, por experiencias anteriores en las que el departamento de reclutamiento se había tardado mucho tiempo en llenar nuestras posiciones, ellos consideraron que sería buena idea dar dos pasos en un solo golpe y me enviaron la propuesta para autorización al mismo tiempo que se la extendían al candidato. Yo la revisé y la autoricé y se la envié al manager funcional en Estados Unidos para ser aprobada. Sin embargo, el manager de USA me comentó que detuviera el proceso porque el proyecto para el que estábamos buscando personal se había cancelado.

Hablé con el personal de Reclutamiento sobre la situación y rechacé la propuesta y solicité cerrar nuestra posición, a lo que el gerente del departamento me contestó que no era posible rechazarla y que necesitaba reclutar al candidato, porque ellos ya le habían extendido la propuesta. Le comenté que yo nunca había autorizado ninguna propuesta y descubrí que ellos se habían saltado ese paso del proceso para agilizar las cosas.

El gerente del departamento de reclutamiento me dijo que ellos sólo estaban tratando de darnos un mejor servicio, y yo le comenté que le agradecía la intención pero que era su obligación servirnos ágil y eficientemente siempre a todos los departamentos y sin favores especiales, y que no debía saltarse pasos de su propio proceso. El respondió un tanto molesto pero aceptando que el error se había cometido en su departamento. Desde entonces cuando lo veo gasto un saludo todas las mañanas y soy correspondido con una mueca parecida a una sonrisa apretada.

Conclusión

Puedo continuar con experiencias vividas, pero creo que he llegado al punto que quería destacar: el personal que contratas es demasiado importante como para dejarlo en manos de desconocidos. Si tu departamento de selección y reclutamiento es efectivo, te felicito, pero si compartes alguna experiencia parecida a las descritas arriba, te recomiendo que te involucres activamente en la selección de tu personal. Asegúrate que tus candidatos están bien informados del tipo de empresa en la que podrían estar trabajando. Ayúdalos a entender detalles acerca de la frecuencia de su pago, la cantidad libre que estarán recibiendo, los horarios, las flexibilidades que maneja la empresa así como aquello en lo que no se flexibilizarán. En resumen, ayúdalos a evitar sorpresas, después de todo esto es un área que un project manager debe desarrollar dentro de sus proyectos.

Por Fernando Valdez

La importancia del inicio del proyecto

Jueves, Julio 14th, 2011

kickoff-meeting.jpgYo fungía como líder de proyectos de sistemas en una empresa mexicana con un portafolio de proyectos extenso. Los proyectos eran para automatizar diferentes aspectos de las áreas de finanzas, cobranza, recursos humanos, servicio a clientes, etc.

En una ocasión el director de ventas me llamó diciendo que estaba por enviarme un email con datos sobre un proyecto que necesitaba que empezáramos cuanto antes. Le dije que lo esperaría y tan pronto como colgamos el teléfono llegó el correo.

Un poco después tome los datos que este director me había enviado y lo capturé en la base de datos de proyectos y en mi revisión semanal con el gerente de desarrollo le mencioné que habíamos recibido una nueva requisición y que necesitábamos priorizarla. Después de algunos comentarios al respecto mi jefe dijo que se comunicaría con el director para discutir prioridades y que después me comentaría como procederíamos con ese requerimiento.

Las especificaciones

El director había sido muy específico en sus requerimientos, mismos que definió a través de su gerente de ventas de la zona norte, así que el documento (por email) tenía especificados muchos detalles hasta con dibujos de pantalla (mock-ups o screen-shots). Al final del correo tenía una estimación de lo que ellos pensaban que debería tomar el desarrollo de ese proyecto. La estimación tenía mucho sentido, dado que el trasfondo de aquellos individuos, el director y el gerente, era de gente de Tecnología de Información.

El pre-análisis

Nosotros no empezamos a desarrollar el proyecto de inmediato, sino que fuimos terminando algunos otros pendientes y de vez en cuando nos reuníamos con ellos para ir esbozando los requerimientos y conociendo las necesidades para decidir acerca de la tecnología a usar.

Cuando los miembros del equipo se liberaron por completo, entonces nos dedicamos un poco más a juntarnos con los gerentes y supervisores para entender y levantar formalmente los requerimientos y después de una semana de hacer esto, el director preguntó si ya íbamos a acabar. El esperaba ver más de la mitad de los entregables implementados a esas alturas.

Cuando le dijimos que apenas estábamos terminando de documentar el análisis el director se incomodó y escaló el problema con mi jefe y con el jefe de mi jefe. Ellos le preguntaron que si había un email o documento en el que yo me comprometía para llevar ese avance en esa fecha, pero el mostró el primer email que me había enviado y mi respuesta allí decía que íbamos a empezar el proyecto tan pronto como revisáramos las prioridades del departamento y asignáramos los recursos. Adicionalmente le daba el número de folio de su requisición que ya había sido dada de alta en el sistema para control de proyectos. De tal manera que no tenía ningún compromiso documentado de mi parte, sólo tenía un par de correos y evidencia de algunas reuniones con otro personal, sin embargo, para el, eso era suficiente como para considerar el proyecto iniciado.

¿Por qué es importante un arranque formal del proyecto?

Un director ha llegado hasta allí por saber tomar decisiones con poca información o por haber desarrollado esa capacidad, el problema es que ellos esperan lo mismo de los que interactúan con ellos. Cuando un director da una orden, normalmente espera que se ejecute de inmediato y espera revisar métricas del desempeño de inmediato.

Hay directores expertos en Project Management, pero no estoy hablando de ellos ahora, ellos seguramente entenderán lo que se requiere para iniciar, planear, ejecutar, controlar y cerrar un proyecto. Yo hablo de aquellos que no tienen dicha preparación, para ellos es necesario un “trato especial”.

Comunicación

Es necesario comunicar cada estado en el que se encuentra el proyecto. Que el director tenga o no tenga experiencia en proyecto o que su estilo sea pedir y esperar de inmediato que todos se pongan a trabajar no es un defecto, es sólo una forma de trabajar. Es responsabilidad del líder de proyectos el comunicar en que etapa del análisis, diseño, desarrollo o control se encuentra el proyecto. Incluso si el proyecto se encuentra en una fase tan temprana como lo es su inicio, es necesario que lo comuniquemos.

El verdadero inicio del proyecto

El PMI® menciona en el PMBOK® que el inicio del proyecto nunca se tiene puntualmente definido en una sola fecha. Esto se refiere a que un proyecto puede nacer en un elevador mientras dos personas platican, por ejemplo, que “sería bueno que implementáramos un control de ventas más eficiente”. Más adelante, tomando este mismo ejemplo, estas dos personas podrían reunirse para comentar un poco más sobre ese asunto. Posteriormente podrían existir algunos correos yendo y viniendo acerca del mismo tema. Y de esta forma podría haber muchas otras comunicaciones que dieran lugar, por ejemplo, a un sistema de información que derivara de aquella iniciativa y que ese sistema de información fuera administrado como un proyecto. De tal forma que tiene sentido lo que el PMI® menciona cuando dice que un proyecto en ocasiones no tiene muy clara su fecha de inicio.

Para el equipo del proyecto, este debería “nacer” en el momento en el que se los involucra en el mismo. Cuando hay una estructura o cadena de mando aquella persona que es contactada para hacerse cargo del proyecto es la responsable de comunicar su progreso o delegar esta función a quien se hará cargo del mismo. Si bien el proceso de aprobación del proyecto o de revisión del portafolio y priorización de proyectos pudiera tomar algo de tiempo, es responsabilidad de la oficina de proyectos o del Líder del Proyecto el comunicar el estatus actual.

El problema

En muchas organizaciones no se tiene una Oficina de Proyectos que administre el portafolio, pero en cambio se tiene una gerencia que administra las operaciones y asigna responsables a los diferentes proyectos de acuerdo a diversos criterios como lo son línea de negocios, cargas de trabajo, etc. De tal forma que en algunas organizaciones nos encontramos con varios líderes de proyectos dependiendo de un gerente quien les asigna el trabajo y estos, hasta cierto punto, administran su propio portafolio que comúnmente consta de 10, 20 ó 30 proyectos que están esperando por prioridad y recursos para ser desarrollados.
La vida del líder de proyectos es agitada: preparar reuniones, asignar recursos, conseguir esos recursos, lidiar con ausencias de personal, ajustar el cronograma, monitorear el registro de riesgos, dar seguimiento a la lista de problemas (issue register), etc. Son algunas de las actividades que pueden mantener el día de un líder de proyectos totalmente ocupado.

Sin embargo, si se encuentra en la necesidad de administrar un subconjunto del portafolio de proyectos de la compañía o del departamento, es necesario que agende periódicamente un tiempo para la revisión de ese portafolio de proyectos que tiene asignado y que comunique el estado actual de los proyectos a los patrocinadores correspondientes.

Saca la cabeza del lodo

Un buen amigo mío y mi jefe en aquel entonces solía decirme “necesitas sacar la cabeza del lodo y respirar”. Efectivamente, para vivir necesitamos respirar. La respiración, que traducido a nuestra profesión representa los tiempos de evaluación, introspección, descanso, planeación  y liderazgo, proporciona a la vida de un líder de proyecto la perspectiva necesaria para resolver los problemas creativamente y también proporciona el tiempo necesario para comunicar los avances de los proyectos, aún cuando éstos no hayan iniciado todavía.

El fin de la historia

El proyecto de aquel departamento de ventas fue iniciado más adelante, después de haber aclarado y comunicado una serie de expectativas a sus patrocinadores.
Dimos un inicio formal al proyecto con la conducción de una reunión de kick-off a la que invitamos a los patrocinadores y a nuestro gerente, así como a los usuarios y nuestro equipo de proyecto. Las actividades que ya habíamos hecho las llamamos pre-análisis y esta etapa la definimos como necesaria para familiarizarnos con la idea que íbamos a transformar en un producto.

Ese fue el inicio real del proyecto desde nuestra perspectiva. Aún cuando el director de ventas pensaba que ya íbamos tarde, nosotros nos esmeramos en comunicar los progresos del proyecto y al final y después de algunas actualizaciones naturales del cronograma el proyecto terminó dando a luz un producto utilizable para ese departamento.

Conclusión

El inicio del proyecto muchas veces es impreciso, pero consideraremos que el proyecto inicia desde el momento en que somos asignados a él.

El líder de proyecto es responsable de la comunicación de un proyecto aún cuando no haya sido iniciado formalmente.

Iniciar formalmente el proyecto es importante, reduce incertidumbre, establece expectativas y le comunica al cliente o usuario que a partir de ese momento empezarán los esfuerzos por parte del equipo (no antes).

Hay que reservar tiempo a la semana para actividades de liderazgo. Este tipo de actividades ocasionalmente son momentos de preparación, reflexión, convivencia con el equipo, comunicación y replanteamiento de lo que se está viviendo en el proyecto.

Por Fernando Valdez

Problemas en el proyecto

Miércoles, Mayo 4th, 2011

problemas.jpgHace tiempo iniciamos un proyecto con muchos entregables, poco tiempo para completarlo, poca definición y de incalculable valor para el cliente… ¿te suena familiar?

Ésta es la vida real.

Los problemas son lo que hacen que el cliente nos llame. Los problemas son los que hacen girar la rueda del intercambio comercial entre clientes y empresas de productos y servicios. Sin los problemas no tendríamos trabajo.

Muchos de los lectores seguramente son personas versadas en las técnicas de administración de proyectos, unos a nivel introductorio y otros avanzado, pero ambos, a su propio nivel, se encuentran diariamente con una serie de problemas que los hace aplicar las diversas técnicas aprendidas ya sea experimentalmente o formalmente para conseguir una solución favorable.

Mi proyecto no fue la excepción. Desde su propio origen nos encontramos con el problema de balancear las variables tiempo, alcance y calidad.

Pensando en esto, en las técnicas y herramientas que hay para resolver problemas de administración de proyectos, me puedo dar cuenta que hay mucho escrito sobre administración de proyectos. Constantemente recibo correos que me invitan a visitar un sitio, a comprar un template, a adquirir una metodología de administración de proyectos, a inscribirme en un curso que me enseñará “lo que nadie en el mercado está enseñando sobre administración de proyectos”, a asistir a la reunión mensual en la que tratarán “temas de relevancia para los administradores de proyectos en estos agitados tiempos”,… la lista continúa interminablemente.

He revisado decenas de metodologías, asistido a más de cien seminarios web, leído miles de páginas, visitado centenares de sitios web sobre administración de proyectos y descargado innumerables formatos y templates para su uso en mis proyectos. Además hice un diplomado en administración de proyectos que resultó en mi certificación como PMP, sin embargo ninguno de estos esfuerzos, algunos gratuitos y otros muy bien cobrados, me dieron las habilidades para resolver los problemas de mis proyectos.

Y es que no solamente se trata de conocimientos y metodologías, se trata de muchas cosas más. Desde luego que los conocimientos adquiridos trabajan a nuestro favor cuando nos enfrentamos a un miembro del equipo ocioso, o cuando balanceamos cargas de trabajo, o cuando necesitamos apresurar la entrega de un paquete de trabajo, o cuando el cliente pide un cambio. Hay suficientes páginas escritas sobre cómo lidiar con estos y otros problemas, pero siempre el nuestro parece algo diferente a lo que dice en el libro de texto.

He observado que hay tres actividades que podemos llevar a cabo para incrementar nuestras habilidades en la resolución de problemas y son las siguientes:

1. Enfrentar el problema. No se trata de darle la vuelta, evitarlo o buscar alternativas, se trata de reconocer que existe y emprender el camino hacia su resolución. Necesitas exponerte a los problemas. Quizás necesites tus habilidades más recientemente adquiridas en el mega-seminario de administración de proyecto o simplemente usar tu sentido común, pero lo importante aquí es concentrar tu atención en la búsqueda de la mejor solución al problema y no en evadirlo.

2. Documentar los resultados de tus esfuerzos por resolver el problema. Esto es algo así como las lecciones aprendidas parciales de tu proyecto. Es tu experiencia. Esto es el legado que vas a dejar al mundo de la administración de proyectos. Es el manual de resolución de problemas que le estás heredando a aquellos que están al inicio, en medio o al final de la carretera que representa la administración exitosa de un proyecto de cualquier naturaleza. Este registro es invaluable. Es lo que todas las compañías deberían estar ofreciendo dentro de sus capacitaciones. No ha habido seminarios más interesantes a los que yo haya asistido que a aquellos en los que se relatan lecciones aprendidas de un proyecto en específico. Es experiencia en acción, es valor agregado en toda su expresión.

3. Buscar problemas por resolver. Ya encontramos problemas en nuestro proyecto, ya los resolvimos, ya registramos las lecciones aprendidas y el problema quedó resuelto. La única manera para practicar la resolución de problemas es exponiéndonos a ellos de manera regular. Si no tienes problemas en tu proyecto seguramente es porque no has observado bien. Si no ves problemas seguramente es porque no has buscado en el lugar correcto. Los problemas están allí, tienen un reloj haciendo tic-tac, a punto de explotar cuando menos nos lo esperamos. Si no buscamos los problemas ellos nos encontrarán a nosotros pero quizás nos encuentren con la guardia baja.

Un proyecto se trata de resolver problemas. El trabajo se trata de resolver problemas. La vida se trata de resolver problemas. Aprende a vivir con ellos, a buscarlos, a identificarlos, a reconocerlos hasta que se vuelva tu segunda naturaleza, aprende a enfrentarlos, aprende a olfatearlos a lo lejos, aprende a prevenirlos antes de que ocurran… esto te dará un altísimo nivel de empleabilidad.

Los mejores administradores de proyectos con los que he tenido el privilegio de trabajar no estaban certificados en Project Management, los mejores no tenían cientos de horas de capacitación en administración de proyectos. Los mejores que yo he conocido sabían identificar problemas, resolverlos, anticiparlos y los enfrentaban agresivamente, inteligentemente y, como una osa que sentía la amenaza de un extraño, embestían el problema hasta dejarlo fuera de combate para siempre.

¿Qué hay de ti y de mí, que nos reunimos virtualmente para compartir esta lección, que buscamos seminarios y lecturas interesantes para afilar nuestras armas para la batalla en el campo de la administración de proyectos?, ¿no deberíamos tener un mejor desempeño?

Así es mi amigo lector, sal, busca y enfrenta tus problemas, pelea la buena batalla, la batalla que está ganada, la batalla de la profesionalización y aplicación de mejores prácticas en el campo de tu experiencia y cuando tengas la victoria documenta, comparte y aprende… y prepárate para el siguiente round.

Te deseo éxito.

Por Fernando Valdez

El staff adecuado del proyecto

Jueves, Enero 6th, 2011

En una ocasión tuve la oportunidad de dirigir un grupo de ingenieros de pruebas para un proyecto de software en el que participaríamos revisando que la traducción del inglés al español de una aplicación se hubiera elaborado adecuadamente. Tendríamos que revisar decenas de pantallas y cientos de textos y, cada vez que encontráramos un error, deberíamos reportarlo en una herramienta diseñada para el reporte de errores.

La experiencia en ese proyecto fue interesante y dedicaré otro post para describirla, pero en esta ocasión quiero comentar sobre la experiencia que tuve trabajando  con ese particular equipo de proyecto. Mi equipo local en México constaba de 5 ingenieros de verificación, pero el equipo en Nueva Jersey, Estados Unidos, estaba compuesto por Desarrolladores de Software, un Project Manager, varios Ingenieros de Testing funcional y dos Stakeholders que compartían la misma característica: todas eran mujeres. A través de las diferentes etapas del proyecto tuve oportunidad de acordar, discutir, negociar, prometer, cumplir y todas las interacciones normales que se tienen en un proyecto con las miembros del equipo y siempre llegamos a acuerdos concretos que finalmente dieron como resultado la terminación satisfactoria del proyecto. No miento si les digo que tuvimos fricciones, retrasos y expectativas temporalmente no cumplidas, pero al final el proyecto fue terminado de acuerdo al plan maestro de la Gerente del Proyecto.

Al final organicé una reunión con mi equipo local para reflexionar sobre nuestro desempeño durante el proyecto (lecciones aprendidas). La reunión fue muy dinámica y todos hacíamos comentarios sobre los cambios de alcance, lo ajustado de las fechas, los problemas de comunicación, etc., pero nunca nadie mencionó las ventajas o desventajas de trabajar con un equipo de personas de diferentes nacionalidades (Norteamericanos, Rusos e Indios y, desde luego, Mexicanos) y completamente del sexo opuesto al nuestro. Y es que, en realidad, eso no era relevante. Todos se habían mostrado enfocados en las metas del proyecto y simplemente fuimos “ciegos” a esos factores. Las compañeras siempre se condujeron profesionalmente y nosotros hicimos también lo propio. Simplemente no había nada de que decir al respecto, todos trabajamos enfocados y profesionales.

Traigo a colación este tema porque no hace muchos años tuve a mi cargo un equipo de proyecto en el que participaban solamente mujeres y yo era el líder del proyecto, todos éramos mexicanos. A los pocos días de haber empezado el proyecto los conflictos empezaron a surgir entre las miembros del equipo, había comentarios y situaciones tensas, el progreso de una de ellas era dificultado por otra hasta que tuve que intervenir y decirle a ambas en una reunión: “no sé qué problema tienen, pero el proyecto se está viendo afectado, necesito que resuelvan su problema porque a este paso no vamos a tener éxito”. Lo que me sugirieron ellas fue separarlas y eliminar toda interacción, pero la verdad es que el equipo era muy pequeño y eso no era factible. Por otro lado, cambiar uno de los recursos en esa etapa del proyecto era poco efectivo, así que tuve que involucrarme y apoyar en su resolución.

Cuando terminé ese proyecto y, dado que en aquella compañía yo tenía un equipo fijo de proyectos (a diferencia de otros lugares en los que se comparte un pool de recursos bajo el mando de un gerente funcional y que participan indistintamente en los diferentes proyectos) tomé la decisión de contratar exclusivamente hombres para mi equipo; según yo eliminaría la variable ‘conflicto’ de mis proyectos, pero la experiencia fue totalmente diferente.

Durante varios proyectos con mi nuevo equipo todo salió muy bien, sin embargo el avance fue lento y los conflictos acerca de la mejor técnica a usar para implementarlo fueron muchos. De tal manera que me puse a pensar detenidamente cuál sería la formula exitosa en la creación de mi equipo. No podía simplemente contratar personas del mismo género, así que consideré algunas otras variables.

A continuación describo variables que me ha sido de mucha utilidad considerar cuando armo un equipo de proyecto:

1. Problemas personales. Todos tenemos problemas, pero aquí me refiero a aquellas personas que tienen problemas que exceden el promedio normal (si es que el término’ normal’ pudiera ser cuantificado). En una ocasión trabajé con una persona con serios problemas de salud en su persona y en su familia. Constantemente solicitaba irse temprano, llegar tarde, salir “un momento”, “trabajar” en casa, etc. Normalmente llegaba a la oficina tarde y bajo el influjo de alguna droga para reducir el dolor o eliminar síntomas de la gripe. Había sido intervenido quirúrgicamente mas de 7 veces de las cuales 3 habían sido situaciones graves. Al menos una vez por mes su familia o él sufrían de algún encuentro cercano con la violencia de la ciudad (robo, amenazas, choques, etc.). A esto me refiero con problemas que exceden el promedio.

mentor-team-copy.jpgEn una ocasión iba manejando de regreso a mi casa y me detuve en un semáforo frente a una empresa que estaba solicitando personal. En el cartelón que colgaba de la puerta principal decía: “Se solicitan operarios. Mayores de 18 años, sexo masculino, SIN PROBLEMAS”. Me dio risa leer eso, pero no decía más que la verdad: un líder de proyectos desea que su proyecto fluya conforme al plan y por eso es necesario tener las habilidades para lidiar con imprevistos, pero cuando uno se enfrenta a una persona que es un imán para los problemas debemos empezar a evaluar si esos problemas son reales o no, pero de cualquier forma se tienen que tomar decisiones para que estos no afecten al proyecto. En una ocasión un miembro muy importante de mi equipo al que todos acudían en búsqueda de respuestas perdió su auto y me solicitó trabajar por los próximos meses en casa, a lo que yo le contesté: “Aquí en la compañía estamos para ayudarte, tienes todo nuestro apoyo pero el problema sigue siendo tuyo. Dime cómo podemos apoyarte para que tu resuelvas el problema, pero te necesito aquí con el resto del grupo”. Este compañero tenía un hermano trabajando en nuestra compañía y que vivía muy cerca de su casa, así que optó por venir a la oficina compartiendo gastos de gasolina y conviviendo más con su hermano.

2. El género. Voy a mencionar mis observaciones trabajando con hombres vs. mujeres

  • Las mujeres aportan mucha continuidad a los proyectos, los hombres normalmente están en busca de mejores oportunidades de trabajo y rotan con mayor frecuencia de una compañía a otra, las mujeres en cambio, cuando se encuentran en una atmósfera agradable de trabajo y su remuneración es justa tienden a “echar raíces”, lo cual es bueno para la estabilidad del equipo.
  • Los hombres tienen dentro de sus prioridades mas altas el trabajo y su desarrollo dentro de la compañía, por lo que estarán buscando hacer las cosas de la mejor manera posible, investigarán nuevos métodos, permanecerán largas horas en la oficina dando solución a los problemas del proyecto y sacrificando en ocasiones su vida personal y familiar, etc., mientras que las mujeres tienen su prioridad más alta en la familia, las relaciones y el equilibrio. Comúnmente las mujeres son más rápidas para dar soluciones porque no invierten mucho tiempo para encontrar la mejor solución, cuando encuentran una solución viable al problema la implementan avanzando mas rápido que muchos hombres.
  • Las mujeres involucran emociones en el proyecto, lo cual agrega una atmósfera interesante y divertida al proyecto, sin embargo esto puede causar conflictos.
  • Los hombres al cabo de un año o más solicitarán un aumento, más responsabilidad o ambas. Esto no es un problema, simplemente necesita ser administrado.
  • He observado que la relación laboral hombre-hombre y hombre-mujer son muy efectivas, pero en muchos de los casos habrá conflictos con relaciones de tipo mujer-mujer. Tiende a haber tensiones mayores a nivel personal.

En general, cuando necesito que un proyecto se realice rápidamente y bien hecho suelo incluir mujeres en el equipo. Por el contrario, si necesito estabilidad en el producto final o se trata de una nueva tecnología o de crear algo no hecho antes elijo hombres, pero mi mejor recomendación siempre será tener un equipo mixto (hombres y mujeres) de gente talentosa y que desea crecer con la empresa.

3. El temperamento. No pretendo hacer de esto un curso sobre los diferentes temperamentos, solamente mencionaré los que han sido definidos por aquellos dedicados a su estudio. Existen cuatro temperamentos básicos: Colérico, Flemático, Melancólico y Sanguíneo. No existe nadie con un temperamento puro, es decir, todos compartimos características de dos o tres temperamentos, pero definitivamente poseemos más características de uno de ellos que de los demás.

Mi recomendación es que investigues cuál es tu temperamento y cuál es el temperamento de los miembros de tu equipo. Muchos de los conflictos personales surgen porque no sabemos como es más efectiva la demás gente. Por ejemplo, si tengo a un colérico en mi equipo desde luego que evitaré dar demasiados detalles en la explicación, iré al grano y dejaré que el o ella investiguen el resto porque sé que es lo que les gusta hacer. Por el contrario, si asignaré una actividad a un flemático no esperaré a que el tome la iniciativa, pero si puedo esperar un trabajo individual excelentemente elaborado. A un sanguíneo lo enviaré a negociar los alcances y a presentar los avances y a un melancólico lo concentraría en la elaboración de índices de productividad o en la inspección de la calidad del trabajo realizado.

Mi mayor recomendación a este respecto es que no busques gente igual a ti o con tus mismas habilidades, mismo carácter o mismos métodos de resolver los problemas, la diversidad hace al equipo dinámico y exitoso.

Esta lista de variables definitivamente no es exhaustiva y contiene elementos meramente basados en mi experiencia y mi opinión, ustedes podrán diferir y abundar en las consideraciones para formar el equipo perfecto aunque creo que dicho concepto no tiene un correspondiente en la realidad.

Conclusiones

Quisiera concluir mencionando algunas acciones que considero necesario implementar para tener un equipo exitoso.

  • Necesitamos buscar que nuestros integrantes del equipo tengan los conocimientos técnicos que estarán utilizando diariamente (hard skills), y capacitarlos para incrementarlos y perfeccionarlos.
  • Debemos desarrollar a nuestros integrantes en el área de habilidades relacionales o soft skills, particularmente en el área de comunicación. Conocí a un contador que era altamente efectivo en la técnica contable, pero que no le gustaba comunicar las malas noticias. Es necesario comunicar las buenas y las malas noticias, después de todo es mejor saber que se tiene cáncer y combatirlo que morir a los pocos meses.
  • Entre los integrantes del equipo debe haber transparencia, respeto y un ánimo por conseguir la calidad en los entregables desarrollados. Cuando se tiene apertura de lo que está sucediendo en el proyecto y en nuestras vidas particulares es mucho más fácil entender los problemas y desarrollar planes alternativos para conseguir el éxito.
  • Debemos ser promotores de la retroalimentación al interior de nuestros equipos. La retroalimentación se hace pronto, sin rodeos y orientada a resolver los problemas, no a molestar a las personas. Una retroalimentación positiva no se hace con respecto a las características físicas o económicas de una persona, sino hacia sus habilidades y su actitud.

Les deseo muy feliz año nuevo y éxito en sus proyectos.

Por Fernando Valdez