Andares de un proyecto

Aceptando el reto

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

Administramos cosas, lideramos personas

Publicado el Septiembre 4th, 2013 en Integración, Recursos Humanos, Comunicaciones, General por admin

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 importancia de los mentores

Publicado el Junio 11th, 2013 en Inicio, Control, Planeación, Calidad, Recursos Humanos, General por admin

Por Fernando Valdez

Llevaba trabajando en una empresa apenas unos dos meses cuando recibí una llamada por teléfono. Contesté y era de Estados Unidos, era un gerente de servicio a clientes de nuestra empresa que a su vez tenía a una persona de finanzas al teléfono y juntos estaban pidiéndome el reporte financiero de un proyecto que yo estaba administrando. La verdad es que nunca había oído hablar de ese reporte y mis interlocutores extranjeros sonaban con mucha prisa por tenerlo en sus manos, ya que era momento de recabar información del proyecto para hacer los cargos correspondientes al cliente. Yo era el único Administrador de Proyectos extranjero (toda nuestra organización estaba basada en la ciudad de Dallas, Tx. y en Cleveland, Oh.) y yo no tenía a nadie a quien preguntarle acá en México. Además, como ya lo comenté, nuestro departamento apenas había sido creado hacía un par de meses fuera de Estados Unidos y nadie tenía la más mínima idea de cómo proceder ante tal petición. Los silencios incómodos empezaron a surgir y los gerentes al otro lado de la línea parecían muy inquietos y temerosos de que no existiera tal reporte, así que les dije que necesitaba 30 minutos para darles una respuesta al respecto. Ellos aceptaron e hicieron hincapié en que ese reporte debería ser enviado a la brevedad posible. Colgamos el teléfono y pensé: “¿que voy a hacer?”.

mentoring-w.jpg
Antes de mencionar cómo resolví el problema, déjenme hablarles un poco sobre nuestra organización y sobre las dos primeras semanas de trabajo en la misma.

Al ingresar a la compañía dos meses atrás, hice un viaje de dos semanas a Dallas, Tx para conocer a mis colegas Administradores de Proyectos y a mi jefe, el director de la Oficina de Proyectos (PMO - Project Management Office). Durante el viaje no solo los conocí, sino que me fueron explicados los procedimientos estándar de la oficina de proyectos, así como los documentos que deberíamos generar y el repositorio para almacenar dichos documentos a través de las diferentes etapas de los proyectos.

Al segundo día de estar en Dallas, mi jefe se acercó a mi escritorio y me presentó a un Administrador de Proyectos Sr. que además apoyaba a la PMO en diversas actividades. Mi jefe mencionó que cualquier duda que tuviera se la preguntara a él, ya que sería mi mentor, y me dijo que él me daría indicaciones durante los próximos días sobre lo que tendría que cuidar dentro de un proyecto.

En un principio esto se me hizo exagerado, porque para entonces yo llevaba alrededor de diez años administrando proyectos y contaba con mi certificación como Project Management Professional (PMP). En teoría todo lo que mi mentor me podría haber enseñado era algo que de alguna u otra forma yo ya había experimentado.

Mi mentor hizo una excelente tarea en mostrarme los detalles específicos de nuestra organización, cómo generar documentación, donde almacenarla y cómo conducir reuniones de equipo presenciales y virtuales con personal de la India y de otros estados de la unión americana, pero hasta  ese momento no habría surgido la necesidad de llenar algún reporte de carácter financiero.

Como Administradores de Proyectos en el área de desarrollo de sistemas computacionales no siempre nos vemos envueltos en la necesidad de manejar presupuestos en pesos o en dólares, sino presupuestos en horas-hombre.

Normalmente hacemos estimaciones de duración de los proyectos y mucho de lo que manejamos son las horas de esfuerzo que un empleado pone en el proyecto. Esto a su vez se traduce a pesos o a dólares ya que cada hora tiene una tarifa que depende de la experiencia y la naturaleza de las actividades a desempeñar por el empleado. Sin embargo, cuando se trata de los clientes, en última instancia todo lo manejamos en términos de una unidad monetaria y de aquí la importancia del reporte financiero del proyecto.

Ahora si, de regreso a la llamada que acababa de terminar con mis colegas de finanzas y de servicio a clientes. Levante inmediatamente el teléfono y le llamé a mi mentor, le expliqué la situación y el me dijo, “ah!, no te había explicado eso porque no era aún tiempo, pero dada la prisa que parecen tener, te voy a ayudar a generar el reporte y después te explico con calma los pasos para obtenerlo”. Mi mentor me dijo cómo hacer el reporte sin muchos detalles, pero dado que yo tenía ya experiencia, pude entender lo que estábamos haciendo para armar tal reporte.

organizaciones-inteligentes-610×250.jpg

Treinta minutos después de esto envié un correo electrónico con el reporte que me habían solicitado incluyendo información sólida sobre las finanzas del proyecto.

Con esto puedo extraer al menos tres experiencias que me han sido muy valiosas en los últimos años como Administrador de Proyectos:

1) Cada empresa tiene diferentes formas de hacer las cosas. Cuando llegues a una nueva compañía trata de entender y conocer los formatos y procedimientos que se manejan allí. Probablemente el reporte de comunicaciones o el cronograma se llamen igual de una empresa a otra, pero en cada una hay una manera diferente de hacerlo.

2) La importancia de tener una PMO y procedimientos estándares para la administración de proyectos. El reporte financiero que me pidieron ya tenía un formato específico e incluía información cuya fuente era ampliamente conocida por todos. Utilizábamos un sistema para capturar las horas dedicadas a cada proyecto en una base semanal, de tal forma que al ejecutar un procedimiento de actualización, dichos números eran cargados automáticamente al reporte financiero y el resto era hacer algunos cálculos muy sencillos, así como comentarios acerca del desempeño del proyecto.

3) La importancia de tener un mentor que apoye a los nuevos empleados o a los mentoria-w.jpgAdministradores de Proyectos Jr. El tiempo que estos mentores invierten en un miembro del equipo es invaluable y la mayormente beneficiada es la empresa, ya que se hace un uso más óptimo de los recursos en lo general.

Mis colegas de finanzas y servicio al cliente ya conocían el formato que les había enviado, así que sólo se concentraron en extraer la información y pudieron cumplir a su vez con su trabajo de manera puntual.
Espero que esta experiencia haya sido útil para ustedes. Hasta la próxima.

Fernando Valdez 

La generación Y dentro de los proyectos

Publicado el Abril 17th, 2013 en Planeación, Integración, Recursos Humanos, Comunicaciones, General por admin

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

Publicado el Junio 5th, 2012 en Recursos Humanos, Comunicaciones, General por admin

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.

Porqué es de suma importancia contar con una PMO

Publicado el Abril 17th, 2012 en Control, Planeación, Grupos de Proceso, Alcance, Recursos Humanos por admin

diverse_business_man_and_woman_40435468.jpg

El término “dejar ir a un empleado” fue acuñado en los Estados Unidos y se refiere al acto de despedir a un empleado, pero desde el punto de vista del idioma Español, éste es un término impreciso, ya que un empleado no está solicitando permiso para retirarse y la compañía no está otorgando dicho permiso. Más bien este término es un eufemismo con el cual se da a entender al empleado que la compañía le está retirando la oportunidad laboral por el motivo que ésta considere conveniente, sin preguntarle su parecer al afectado.

Como quiera que sea, hace un par de meses “dejamos ir” a dos Project Managers de nuestra organización, presuntamente por su bajo desempeño. La misma noche que ocurrió esto, una de las afectadas publicó en su muro de Facebook que “no entendía el porqué de la decisión”. Esta situación me hizo reflexionar acerca los motivos que dieron lugar a su despido, muy al margen de opiniones subjetivas acerca de su desempeño, considerando sólo los hechos. Llegué a una conclusión basado en algunos hechos históricos que a continuación les comento.

Yo llegué a esta organización (mi trabajo actual) ocupando un puesto de Project Manager (al igual que mis dos compañeros que fueron despedidos). Mi organización consistía de un director de la PMO (Project Management Office u Oficina de Proyectos) y alrededor de diez Administradores de Proyectos técnicos (de tecnología de información). Después de dos años fui promovido a Gerente de Tecnología para el área de Monterrey, México, dado que la oficina local iba a crecer a más del doble y se requería una cabeza que administrara las operaciones locales. Un par de meses después de haber aceptado la promoción, la Oficina de Proyectos desapareció y los Administradores de Proyectos fueron movidos a diferentes áreas de la organización, principalmente al área de Servicio a Clientes, donde ahora administraban los proyectos de inicio a fin (contacto con el cliente, creación y autorización de proyectos, levantamiento de requerimientos, desarrollo del proyecto, cierre, seguimiento post-implementación, etc.), no sólo la parte técnica.

La rutina semanal durante mi trabajo como Administrador de Proyectos era más o menos la siguiente:

  • Lunes: Reunión general con el equipo para revisar avances. Cálculo de avances y entrega de reportes de avance a la Dirección de Proyectos (quien a su vez informaba a la alta gerencia).
  • Martes: Junta de planeación de recursos o Staffing meeting. En esta reunión nos juntábamos la alta gerencia, el equipo de autorización de proyectos, todos los gerentes funcionales, todos los gerentes de solución y todos los gerentes de proyectos. En esta reunión evaluábamos la participación de cada individuo (programador, arquitecto, ingeniero de calidad, administrador de proyectos, etc.) en los diferentes proyectos que habían sido autorizados, basándonos en la experiencia de cada individuo en las diferentes herramientas o áreas del negocio a atender. Por ejemplo, verificábamos si era factible tener a Juan en el proyecto X que requería de sus conocimientos técnicos. Lo mismo para Pedro, Hugo y Guillermo, basados en los mismos criterios (habilidades, conocimientos técnicos, conocimientos del área de negocio, experiencia dentro de la organización, importancia del proyecto, importancia del cliente, etc.). El resultado de esta reunión era un portafolio de proyectos con recursos tentativamente comprometidos para cada proyecto en determinada fecha. Esto nos permitía tener una versión tentativa de lo que iba a estar haciendo cada recurso de nuestro personal en el futuro cercano (es decir, los próximos dos meses).
  • Miércoles: Día normal de trabajo. Revisión de avances a nivel local (cada PM con su equipo).
  • Jueves: Reunión del Project Stearing Team (Equipo de Dirección de Proyectos). Este equipo se encargaba de elegir los proyectos a empezar y de priorizarlos de acuerdo con diferentes criterios, como eran: tamaño del proyecto, importancia del proyecto, urgencia del mismo, cliente a atender, etc. También los jueves teníamos la junta de la PMO en la que el director revisaba que nosotros, los líderes de proyectos, siguiéramos con el proceso de documentación, actualización de estadísticas y con cada paso definido en nuestro Ciclo de Vida de Desarrollo de Sistemas (SDLC por sus siglas en inglés). En esta junta teníamos oportunidad de mencionar si veíamos algún riesgo aumentando en probabilidad de ocurrir, mencionar sobre problemas sin resolver o sobre algún miembro de la organización que estuviera obstaculizando el progreso de nuestro proyecto. Si esto último era el caso, el director de la PMO tendría una reunión con la persona que estaba obstaculizando el proyecto y se avocaba a resolver el conflicto y permitir que el proyecto siguiera un curso adecuado.
  • Viernes: Revisión de avances y actualización de métricas. Aquí cada empleado capturaba las horas dedicadas a cada proyecto y a cada actividad realizada durante la semana. Además llenaban un reporte de las actividades que estaría realizando las próximas cinco semanas de acuerdo con los planes que se le habían entregado. Adicionalmente, se hacía un reporte de horas a cobrar a los clientes en el futuro cercano basados en las horas que facturaban los empleados. Todo esto nos daba mucha información que utilizaríamos para tomar decisiones para las siguientes actividades de nuestro equipo de proyecto.
  • Sábado y Domingo: Si habíamos sido exitosos en cumplir los objetivos semanales y si no había ninguna urgencia por parte del cliente, entonces podíamos descansar. En ocasiones, cuando trabajaba con personal de la India, yo iniciaba mi semana el domingo a las 9:30 de la noche, comunicándome con los miembros de mi equipo allá y dándoles dirección para el inicio de la semana, ya que para ellos eran las 9 de la mañana del lunes (iban adelantados 11.5 horas).

No quiero decir que durante el día sólo realizábamos las actividades arriba descritas. Cada día era un reto equilibrar las actividades administrativas, de personal, reportes y muchas más necesarias para el correcto funcionamiento del equipo. En ocasiones, como lo mencioné en un post anterior, era necesario ver por las necesidades de cada miembro del equipo llegando hasta el extremo de verificar si habían comido ese día o no. Eliminar obstáculos que amenazaban el avance del equipo, coordinar las comunicaciones, resolver conflictos, etc. eran actividades diarias para mí como líder de mis proyectos, agregando la complejidad que supone tener a medio equipo a 750 km de distancia y la otra parte del mismo, al otro lado del mundo.

outsourcing.jpg

 Algunos amables lectores se estarán preguntando: “¿qué tiene que ver todo esto con los dos compañeros que despidieron?” Permítanme contarles lo que ocurrió posterior a mi promoción y salida de la PMO.

Cuando el departamento de tecnología dejó de administrar los proyectos y esta administración pasó al departamento de servicio a clientes, algunos compañeros líderes de proyecto no se sintieron muy cómodos y renunciaron, lo que provocó que la organización perdiera experiencia, disciplina y estructura en la administración de proyectos y, al mismo tiempo, nos hizo vulnerables al desorden y la falta de lineamientos administrativos que la PMO brindaba a la organización. Esto no fue evidente de inmediato, sino que poco a poco ha ido revelándose como un problema que necesita solución y al que no muchos aceptan como un error de la administración general de la organización.

En un intento por regresar a “la normalidad”, el departamento de tecnología contrató dos Líderes de Proyecto (exactamente, tal como lo sospechan, contratamos a los dos líderes de proyecto que acabamos de “dejar ir”). Estos dos compañeros hicieron todo lo que pudieron: tomaron sus herramientas de administración de proyectos y planearon el alcance de sus proyectos, monitorearon su ejecución, documentaron riesgos y facilitaron la comunicación. No todas las decisiones que hicieron fueron las mejores, pero definitivamente tuvieron aciertos durante su gestión.

Desafortunadamente, dado que los recursos no les pertenecían del todo (en una organización funcional los recursos le pertenecen a un gerente funcional que los pone en préstamo para el desarrollo de los proyectos y cuando el proyecto acaba, los recursos son regresados a lo que llamamos “el pool” de recursos en espera de otro proyecto), en ocasiones les retiraban o les sustituían personal por otro menos capaz o menos apropiado para el trabajo, lo que impactaba enormemente al proyecto y, desde luego, a su reputación como líderes del proyecto.

A la vuelta de un par de años, en un recorte de gastos, los administradores de proyectos fueron puestos a disposición del mercado laboral global como ya lo mencioné al inicio de esta entrada.

¿Cuál fue la diferencia de estos dos líderes de proyectos y aquellos que formamos el primer grupo de administradores de proyectos en la organización? Mi respuesta a esta pregunta, para hacerla muy breve, es que aquellos que estábamos antes pertenecíamos a una PMO.

La Oficina de Proyectos no sólo nos daba herramientas para administrar nuestros proyectos, sino que establecía el estándar de trabajo dentro de la organización. Adicionalmente el Director de la PMO abogaba por los proyectos desde una posición jerárquica superior a la que teníamos los Gerentes de Proyectos. Y por último, las reuniones de planeación de recursos (Staffing Meeting) y la junta de la PMO, resultaron ser claves para el control del personal y para comprometer a los recursos adecuados a permanecer dentro de la fase más crítica de los proyectos.

No soy especialista en Oficinas de Proyectos, pero sí fui un usuario muy afortunado de la misma. La “protección” con la que se contaba en una PMO ofrecía la estabilidad que un Project Manager necesita para realizar su trabajo efectivamente. Los principios, las lecciones aprendidas, la metodología, los formatos, los estándares y las herramientas eran transferidos a todos los miembros del equipo de la PMO reduciendo así dificultades e incrementando las probabilidades de éxito individual de los miembros.

dynamiclifedevelopment3019.jpg Quizá en la organización a la que los apreciables lectores pertenecen, no exista una oficina de proyectos que provea dirección y facilite su gestión. Incluso quizá se haya juzgado a uno que otro buen elemento por su falta de habilidad para administrar los proyectos, pero si en una organización que maneja proyectos, los líderes de los mismos no tienen un respaldo formal y no se encuentran adecuadamente ubicado en el organigrama, es muy probable que seguirán teniendo algunos éxitos y muchos fracasos en el desempeño de sus proyectos.

Cuando un líder de proyectos le reporta a un gerente de sistemas, se convierte en un líder-de-proyectos-de-sistemas. Cuando un líder de proyectos le reporta a un gerente de operaciones, se convierte en un líder-de-proyectos-de-operaciones. Y así sucesivamente. La organización necesita líderes de proyectos con influencia en toda la organización. Un proyecto de sistemas no solamente involucrará una pieza de software, porque el software no es nada si no tiene usuarios. En un proyecto de software comúnmente se requerirá involucrar empleados de otros departamentos como mercadotecnia, servicio a clientes, operaciones, ventas, productos, calidad, etc. Un líder de proyectos debe poder dar seguimiento a todas las fases del proyecto, o como le llaman en mi organización, un enfoque end-to-end —de inicio a fin— desde la concepción hasta la operación. Cuando un proyecto se entrega, entonces se da a luz un producto y es aquí cuando ocurre el “cambio de estafeta”, de un líder de proyectos a un líder de producto que se encargará de administrar la relación con el cliente y con el equipo de operaciones que lo mantiene en funcionamiento.

Quizá como conclusión a esta reflexión, puedo decir que este es un asunto de autoridad. Si los líderes de proyecto no son investidos con la autoridad que su puesto requiere y a lo largo de toda la organización, entonces no dejarán de ser empleados de un departamento que hacen lo que el gerente de ese departamento necesita. Se perderá la visión general y será muy difícil alcanzar los objetivos globales de la compañía.

Cuando mi organización “dejó ir” a esos dos Project Managers, se deshizo de dos empleados de tecnología que, de acuerdo con la percepción general, administraban los proyectos y, a veces, los obstaculizaban. Suena injusto, ¿no es cierto?

Fernando Valdez

 

La productividad de un líder

Publicado el Febrero 29th, 2012 en Ejecución, Recursos Humanos, Comunicaciones por admin

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

Publicado el Noviembre 16th, 2011 en Recursos Humanos, Comunicaciones por admin

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

El staff adecuado del proyecto

Publicado el Enero 6th, 2011 en Inicio, Planeación, Recursos Humanos, Comunicaciones por admin

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 

¿Tú como project manager cultivas tu cultura general?

Publicado el Noviembre 9th, 2010 en Recursos Humanos, General por admin

“Era una delicia platicar con ellos. Podías pasar una tarde muy amena y los temas relacionados con geografía, historia, política, arte entre otros, fluían de manera natural y escurrían virtuosamente de la boca de aquellos médicos. Eran una generación preparada, ellos habían ido más allá de su llamado vocacional y se habían convertido en personas cultas y, desde luego, los mejores practicantes de la medicina en cada una de sus especialidades”. Esa fue parte de la nota de apertura en un congreso nacional de medicina que aglutinaba médicos de varias especialidades y en la que se hacía referencia a una generación de médicos de los años 70s, un grupo de especialistas médicos que ejercían su profesión, pero más allá de sus amplios conocimientos en su especialidad mostraban un gran conocimiento de la sociedad y del funcionamiento del mundo en el que ellos vivían.

No, no me equivoqué de foro, estoy escribiendo para LiderDeProyecto.com, estoy consciente de eso. Traigo a colación ese tema porque me pregunto, ¿cuántas veces he escuchado ese comentario en alguna reunión de Project Management?

null

La cultura general en la Administración de Proyectos

Como Líderes de Proyectos necesitamos cultivar una cultura superior a la de los practicantes de muchas otras disciplinas. Algunos dicen que PM (Project Manager) son las iniciales de People Manager (Administrador de Gente) y eso no está muy alejado de la realidad. Cuando se trata con personas afrontamos un sinnúmero de circunstancias que nos obligan a cultivar una mayor cultura. En mi experiencia como líder de proyectos he tenido que tratar con temas de matrimonio de la gente que me reporta, trabajo, situaciones familiares, religión, costumbres, viajes, vacaciones, motivación, etc. Cada día tengo la oportunidad de tratar con una nueva situación. He tenido gente delante de mí con situaciones realmente conmovedoras y otros con situaciones divertidas o afortunadas, y es imposible tratarlas con la misma ‘técnica’.

No se diga si administras un equipo virtual. Es necesario conocer fechas especiales en el calendario de aquellos que están trabajando remotamente a tu oficina, celebraciones religiosas y diferencias culturales son áreas con las que he tenido que tratar en más de una ocasión.

En China las personas no sienten que han llegado a un nivel aceptable de involucramiento si sólo se atienden asuntos laborales, ellos esperan compartir situaciones personales incluso al punto de preguntar abiertamente cuál es tu compensación económica mensual. En India aquellos varones que son muy amigos se sienten libres de caminar por la calle abrazando a su amigo (otro varón) sin sentir vergüenza o miedo de ser discriminados socialmente. En México acostumbramos a tocar temas personales en el ambiente laboral. En Estados Unidos puedes rechazar fácilmente una invitación diciendo ‘ya tengo planes’. Como estos hay muchos ejemplos que existen de la diversidad cultural en el mundo y de los que debemos estar conscientes si es que nos corresponde.

Aspectos culturales que debe conocer un Project Manager

Vamos a lo práctico: ¿qué es lo que se supone que deberías saber? Para contestar esta pregunta necesitas responder a otras tantas, como: ¿qué características tiene tu proyecto?, ¿quienes son tus clientes?, ¿quienes son los miembros de tu equipo?, ¿en qué industria se desarrolla tu proyecto? Aquí quiero hacer un alto. Dicen que la pregunta más antigua en Project Management es ¿qué es mas importante para un PM, ¿conocimiento de la industria o conocimiento de Project Management?? La respuesta que ha ‘vendido’ el PMI (y no me malinterpreten, yo soy PMP certificado por el PMI) es que necesitamos conocimiento de Project Management y no discuto con la necesidad de esos conocimientos, pero creo que tenemos que desarrollar un amplio conocimiento de la industria en la que nos desempeñamos para poder completar el bagaje de competencias que nos ayuden a conducir un proyecto al éxito.

¿Has contestado alguna de las preguntas que hice en el párrafo anterior? Si es así entonces estás empezando a distinguir algunas áreas que dominas y otras que no lo has hecho del todo bien.

Para hacer las cosas más fáciles termino con una lista de aspectos necesarios por dominar:

  • Computación (saber usar un procesador de palabras, hoja electrónica de cálculo y software para presentaciones)
  • Redacción (al menos redacción de reportes técnicos)
  • Ortografía (al menos la de las palabras mas usadas en la jerga de PM)
  • Liderazgo
  • Delegación de tareas
  • Un segundo idioma (aquel que se requiera más en tu área de desarrollo)
  • Geografía (como mínimo la local y los países vecinos)
  • Zonas horarias (por lo menos ubicar al meridiano de Greenwich y la(s) que le corresponde(n) a tu país y al de tus clientes y colaboradores
  • Historia (es impresionante la cantidad de preguntas que he recibido de todo el mundo con respecto a nuestra historia de México. En ocasiones me he topado con extranjeros que conocen mejor nuestra historia que nosotros mismos)
  • Política (por lo menos los sucesos más conocidos internacionalmente, locales y extranjeros)

Como habrás visto la lista anterior no es exhaustiva y me encantaría que en los comentarios de retroalimentación a este post tú nos apoyes con tus opiniones y tu propia experiencia. Quizás mi última recomendación acerca de la cultura general que debe tener un líder de proyectos es la siguiente: nunca es tarde para incrementar tu acervo cultural: enrólate en una capacitación este mismo mes, este semestre, este año, no lo dejes pasar, el tiempo no regresa.

Por Fernando Valdez

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.