Aceptando el reto

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

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

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

Junio 11th, 2013

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

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

La necesidad del PM de involucrarse en el conocimiento del negocio

Febrero 28th, 2013

business_men_low_blanc.jpgMi perfil siempre ha sido técnico, muy en específico, en el campo del desarrollo de sistemas. He pertenecido a equipos de trabajo como desarrollador de pantallas, diseñador de bases de datos, implementador, tester, líder de proyectos, etc. Los equipos a los que he pertenecido han sido de dos, tres o cuatro integrantes y últimamente he participado en proyectos enormes de más de 35 personas simultáneamente, todos en el ámbito del desarrollo de aplicaciones de software para pequeñas, medianas y grandes empresas, nacionales e internacionales.

Sin embargo, a pesar de esta experiencia, nada se puede comparar a la que tuve hace algunos meses cuando un amigo mío me invitó a colaborar en un proyecto para la construcción de un museo de arte. Como nos conocíamos bien y el sabía de mi experiencia en administración de proyectos, me habló y me pidió que le apoyara en la construcción de una propuesta para presentarla a un reconocido artista mexicano, quien tenía la intención de dar a conocer su obra e inmortalizarla  ya que estaba llegando al ocaso de sus días.

El proyecto me entusiasmó y tuve varias platicas con mi amigo y con el artista a fin de entender la visión que tenían del proyecto. En mi más simplista perspectiva pensé que se trataba de ensamblar un pequeño grupo de profesionales que incluyera un arquitecto y algunos otros especialistas en el área del arte para que pudieran apoyar en el acomodo de las piezas. Sin embargo mi visión no solo era simplista sino miope, ya que desconocía el mundo que está detrás del arte y mucho más detrás de la creación del museo.

Quiero ahondar más sobre este proyecto, pero lo haré en un post subsecuente, lo que quiero enfatizar hoy es la necesidad que tenemos los líderes de proyecto de involucrarnos en el conocimiento del negocio al que pertenece el proyecto que vamos a administrar.

Un PM tiene que familiarizarse con el medio que lo rodea, el ambiente de proyecto, la gente y el estilo propio de su profesión hasta naturalizarse de esa profesión, para poder entender lo que es realmente importante para los clientes y usuarios y, en última instancia, defender los intereses de estos. Primero necesitamos llegar a dominar el negocio como un verdadero experto y en un tiempo record, después vendrá la aplicación de los conocimientos de administración de proyectos.

Allá por 1986, cuando empecé a aprender el lenguaje de programación BASIC, el libro que estaba utilizando recomendaba que antes de hacer cualquier programa de computo, tendría que conocer todo acerca del negocio. Cuando estaba a punto de graduarme de ingeniería en sistemas, un profesor que nos enseñaba Bases de Datos nos comentó que cuando nos graduáramos la única especialidad que tendríamos sería en análisis de datos, programación y, si acaso, estadística, pero que todas estas herramientas no servirían de nada si no hubiera un negocio en el cual aplicarlas.

Casi cualquier institución académica va a centrar sus esfuerzos en prepararnos para el uso y aplicación de herramientas: una certificación en administración de proyectos no es la excepción.

business_intelligence-low-blanc.jpgCuando entré a trabajar en la industria bancaria desconocía todo acerca de bancos, pero fue la experiencia que me transmitirían mis compañeros y mi jefa las que me prepararían para poder resolver los problemas reales del negocio usando las herramientas que yo había aprendido en la universidad. Cuando trabajé para la industria de las telecomunicaciones ocurrió lo mismo, era un neófito en ese ámbito, sin embargo los proyectos, las entrevistas con las áreas técnicas y administrativas de la telefónica, fueron formando en mi un cuerpo de conocimientos en el área de las telecomunicaciones que más adelante me convertirían en un buen líder de proyectos.

Cuando tenemos mucha experiencia en un área, nos volvemos muy propositivos y eficientes, pero también nos encajonamos en las experiencias que hemos tenido en el pasado y cuando hacemos nuestras propuestas solemos decir “esto funcionó en este otro proyecto, hagámoslo así aquí también…”. Pero cuando uno se enfrenta a un cambio de paradigma como el que experimenté cuando me involucré en el mundo de las artes, es cuando surge la humildad y apagamos el “piloto automático” para poner atención a cada necesidad del cliente. Nuestros colaboradores se convierten en nuestros maestros aun cuando el líder del proyecto eres tú y esto es una experiencia invaluable de conocimiento y colaboración.

Mi invitación para ti en este momento es que cualquiera que sea el proyecto en el que te vas a involucrar, lo hagas como si fueras un neófito en el negocio. Si conoces todos los detalles del negocio, de todas maneras asegúrate de conocer las necesidades más importantes del cliente. Si desconoces el negocio, entonces investiga, pregunta, colabora con todos los profesionales involucrados para entender perfectamente las necesidades y las costumbres del negocio antes de empezar a administrar el proyecto.

Fernando Valdez

El valor de los entregables intermedios

Septiembre 14th, 2012

En la administración de proyectos nos encontramos con diferentes situaciones que nos llevan a tomar decisiones muy relevantes. Mas allá de las decisiones tradicionales a las que nos enfrentamos, como lo son la elección de la metodología que usaremos para administrar el proyecto, la cantidad adecuada de recursos a dedicar en la construcción de entregables y la frecuencia de revisiones de calidad que haremos, existen algunas decisiones no tan comunes que también tenemos que hacer.

En algunos casos los proyectos son complejos y requieren la adquisición o renta de artefactos que  harán posible la construcción de los entregables finales del proyecto. En estos casos necesitamos planear concienzudamente para determinar qué se necesita construir o adquirir aún cuando el cliente no lo haya solicitado, y aún lograr que el proyecto resulte rentable dentro de un plazo razonable.

En una ocasión administré un proyecto en el que el cliente tenía una base de datos con información de direcciones postales de sus propios clientes, pero que no estaba estandarizada, es decir, algunos clientes que vivían en la misma colonia tenían capturados sus datos, por ejemplo, como colonia ‘Santa Martha’ mientras otros clientes de la misma colonia tenían capturado ‘Sta. Martha’ (abreviado) y otros ’Santa Marta’ (sin ‘h’ intermedia), etc.

El cliente decidió que estandarizaría su información basándose en el sistema nacional de direcciones, definiendo el nombre de la colonia tal como el Servicio Postal Mexicano (Sepomex) lo definiera. Sepomex nos envió su base de datos de colonias y nosotros iniciamos el proyecto.

aprietos.jpgDurante la planeación no tardamos en darnos cuenta que más que un proyecto, estaríamos realizando un trabajo operacional (repetitivo) que requeriría varias personas capturando información y homologando las colonias de toda la base de datos d  e los clientes. Pensamos en facilitar esta tarea desarrollando un sistema que identificara patrones encontrando la mejor opción para ese nombre de colonia, por ejemplo, si algún cliente tuviera la colonia ‘Sta. Martha’, que el sistema lo sustituyera por ‘Santa Martha’. Esta idea, aunque buena, estaba incompleta porque tendríamos que estar alimentando al sistema con todas las posibles opciones para cada colonia. Además la información contenía errores tipográficos (mejor conocidos como ‘error de dedo’ al momento de capturar), como por ejemplo: ‘Santa Narta’ (’N’ en lugar de ‘M’) o ‘Sta Marta’ (sin punto en la abreviatura y sin ‘h’). la cantidad de opciones era ilimitada y, si bien nuestro sistema cubriría la mayoría de los casos, existía la necesidad de dar una segunda y probablemente una tercera revisión general a todos los datos para asegurarnos de que todos estuvieran bien clasificados.

Otra idea que se nos ocurrió fue el hacer un sistema que mostrara del lado izquierdo de la pantalla el dato original proveniente de la base de datos del cliente y del lado derecho de la pantalla la información proveniente de Sepomex. El interfaz de usuario cargaría la información del cliente y realizaría la búsqueda dentro de la base de datos de Sepomex encontrando las mejores opciones dentro de esta base de datos y desplegándolas del lado derecho. El usuario elegiría manualmente la opción que mejor se adaptara y almacenaría el registro con la información elegida.

Realizamos el sistema e hicimos pruebas y determinamos que una combinación de las dos propuestas anteriores era la mejor opción (un proceso automático para aquellos patrones más comunes de error (como ‘Sta. Martha’) y el proceso semi-manual en el que el usuario elegiría la mejor opción de las que se le presentaran).

Hasta este punto he explicado mucho acerca del proyecto, pero desglosando, ¿cual era el entregable real para el cliente? Al cliente no le interesaba lo que hiciéramos para alcanzar el objetivo para el que nos contrató, que era el ‘limpiar’ su base de datos y tener consolidada toda su información.

Así que dentro de nuestra planeación tuvimos que considerar la elaboración de un par de sistemas intermedios para alcanzar el objetivo con mayor rapidez y precisión. Este sistema fue cotizado, pero eventualmente nosotros fuimos los usuarios u operarios del mismo y no el cliente.

¿Es ético cobrar por esto? Definitivamente. El cliente nos contrató por nuestra habilidad para resolver los problemas… sus problemas, y si esto implica viajar, construir, rentar, destruir o cualquier otra actividad ética, entonces es válido.

En una ocasión vi un programa de televisión en que para la construcción de un mega puente se requirió el uso de una grúa que no existía en el mundo. El Líder del Proyecto buscó en los diferentes países y nunca encontró una grúa con las dimensiones que el necesitaba, así que tuvieron que construir una versión muy básica de grúa con los materiales que tenían y finalmente la utilizaron para la construcción del puente. ¿Qué pasó con la grúa después de terminado el proyecto? La desmontaron y vendieron por partes (como material).

PMOEn lo personal creo que podrían haber vendido el prototipo a una empresa dedicada a la construcción de grúas y satisfacer esa necesidad del mercado, pero supongo que no sería demasiado rentable dado que no todos los fines de semana se construye un mega puente en el mundo, pero el tema aquí es que es necesario considerar el potencial de los entregables intermedios y, finalmente, considerar su costo.

En muchas ocasiones no cotizamos los entregables intermedios y salimos perdiendo. Hay que prever estos gastos y planear un destino para ellos, como en el ejemplo anterior, si se requiere de construir una grúa muy específica, se deberá planear su venta ya sea completa o por piezas una vez que se haya dejado de utilizar.

A veces los materiales usados en los entregables intermedios pueden ser rematados o vendidos para recuperar algo de capital. La basura de unos es el tesoro de otros.

En ocasiones la construcción de objetos, herramientas o entregables intermedios causa un ahorro para el proyecto, porque si bien elaborarlas tiene un costo relacionado, su uso ahorra tiempo, aumenta la productividad de los integrantes o aumenta la calidad de los entregables finales del proyecto. Esto representa ahorro que a todas luces impacta positivamente al presupuesto.

Si un entregable intermedio no representa un ahorro, muchas veces justifica su construcción el hecho de que no es posible elaborar los entregables finales sin el.

La construcción de un entregable intermedio definitivamente deberá estar en el plan del proyecto, aún que algunos miembros del consejo de aprobaciones del proyecto no estén de acuerdo con su construcción. Aquí debe ponerse en uso las habilidades del administrador de proyectos para “vender” la necesidad al consejo.

El objetivo final de cualquier proyecto en el sentido más práctico, es resolver un problema, pero este objetivo se tiene que alcanzar resolviendo todos los aspectos relevantes del proyecto.

Control de las emociones de un Líder de Proyectos

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.

Porqué es de suma importancia contar con una PMO

Abril 17th, 2012

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

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