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

Los indicadores de avance del proyecto

Publicado el Febrero 27th, 2014 en Ejecución, Control, Seguimiento, Planeación, Alcance, Comunicaciones, Riesgos, General por admin

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

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

La necesidad del PM de involucrarse en el conocimiento del negocio

Publicado el Febrero 28th, 2013 en General por admin

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

Publicado el Septiembre 14th, 2012 en General por admin

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

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.

¿Cuál es la mejor herramienta del Líder de Proyectos?

Publicado el Septiembre 21st, 2011 en Documentación, General por admin

herramienta_ejecutivo.jpgTodos necesitamos de herramientas para desarrollar un trabajo específico. Los médicos tienen su instrumental, los carpinteros tienen sus herramientas y el caso de los Líderes de Proyectos no es muy diferente.

Me he encontrado diferentes respuestas a la misma pregunta mientras entrevisto a candidatos para ocupar una posición de líder de proyectos, algunos opinan que un sistema para creación y control del cronograma tal como Microsoft Project o Primavera son esenciales dentro de la caja de herramientas de un Project Manager, otros se conforman con Microsoft Excel, algunos son más sofisticados y dan una lista de acrónimos de lo que probablemente sean sistemas de código abierto para la asistencia en la labor de administración del proyecto.

La realidad es que no hay una respuesta única para esta pregunta, eso va a depender de la complejidad del proyecto, de los estándares de la organización en la que se desarrolla el proyecto y en última instancia de las preferencias y experiencia del Líder del Proyecto.

El que es martillo…

Cuando una persona es buena utilizando una herramienta, normalmente quiere utilizarla para todo lo que se le pone enfrente. Hace muchos años tuve un jefe que quería que hiciéramos un sistema para el departamento de servicio a clientes en Microsoft Access. Cuando le dije que las capacidades visuales de esa herramienta no eran muy poderosas me dio una cátedra de cómo si lo eran. Después le argumente que necesitaríamos que los datos fueran almacenados en un servidor al cual se conectaran todos los agentes para usar, actualizar y agregar información, a lo que él respondió con otra cátedra de cómo hacer que aquella base de datos, que está pensada para trabajar monolíticamente (base de datos + interfaz de usuario) podría ser usada también en el esquema que necesitábamos. En fin, haciendo la historia corta esa pudo haber sido mi capacitación más rápida y completa en esa herramienta. Terminé convencido de realizar el sistema con esa herramienta de manera temporal, mientras realizábamos el sistema a más grande escala.

La moraleja de esta experiencia es que el que es martillo a todo le ve cara de clavo. En el terreno de la administración de proyectos sucede igual, cuando dominamos una herramienta creemos que todo puede realizarse con ella.

Entonces… ¿que usar?

La elección de la herramienta, como lo mencioné antes, debe obedecer a aspectos como los estándares usados, el tamaño del proyecto y la preferencia del administrador del proyecto, sin embargo sí podemos hablar de algunas herramientas básicas que pudieran ser útiles independientemente del proyecto en el que se trabaje.

Las dos herramientas

La existencia de un líder de proyectos en una organización revela la estructura de la compañía: una compañía que implementa proyectos internos requerirá tarde o temprano de una base de datos con la información de esos proyectos. Algunos le llaman “base de datos de proyectos”, otros le llaman “pipeline” (tubería por donde entran los proyectos) o simplemente portafolio de proyectos.

La primera herramienta necesaria es un sistema en el que se pueda administrar esa lista. Puede ser una hoja de cálculo con los datos relevantes de cada proyecto o un sistema hecho en casa en el que se permita modificar el status, capturar detalles, anexar documentación y otras tareas útiles para el seguimiento y registro de un proyecto.

En la compañía en la que trabajo manejamos el Rational Clear Quest, que es un sistema adaptado a nuestras necesidades para la administración de requerimientos, generación de estimados, seguimiento de entregables, registro de fechas planeadas y reales y para reporteo.

Cuando la lista de proyectos esta almacenada permite su revisión, evaluación, priorización, arranque, cancelación, etc.

La segunda herramienta sirve para el trabajo diario de un líder de proyecto. ¿cuáles son las actividades que un líder de proyecto realiza de manera cotidiana? Si me preguntan a mi yo daría la siguiente lista:

  • Seguimiento a fechas importantes
  • Seguimiento a construcción de entregables
  • Comunicación de novedades a miembros del equipo
  • Comunicación de novedades a la gerencia
  • Revisión y administración de los riesgos
  • Administración de la lista de problemas
  • Pronosticar fechas de fin de etapa y del proyecto
  • Etc.

Si se trata de un líder de proyectos más involucrado en asuntos técnicos, entonces la lista crece enormemente, porque además tendrá que lidiar con las tareas específicas de cada profesión.

La herramienta más flexible que puedo nombrar para este efecto es una hoja de cálculo.

Recuerdo que cuando entré a trabajar en mi actual compañía la oficina de proyectos estaba muy bien establecida y el seguimiento y reporteo se daba con una combinación de Microsoft SharePoint y Microsoft Excel.

La hoja en Excel era una verdadera pieza de arte. En la primera hoja se podía ver un resumen de los proyectos asignados al Administrador del Proyecto con información relevante como el centro de costos a ser cargado, estimado de horas, fechas de los milestones principales, etc.

A partir de la segunda hoja incluía una hoja por cada proyecto al que se le estaba dando seguimiento. Al lado izquierdo venia una lista del personal asignado al proyecto y el tiempo que actualmente había invertido en el mismo (esto lo obtenía Excel ejecutando una consulta de la base de datos de horas invertidas en cada proyecto). De lado derecho incluía una tabla que indicaba el tiempo planeado vs. el tiempo real invertido en las diferentes fases del proyecto, la varianza entre los valores anteriores, el estimado de tiempo para completar el proyecto (ETC), el estimado de horas finales totales (EAC) y la varianza en horas finales totales vs. lo planeado (VAC). Esta sección incluía una serie de banderas de colores que cambiaban automáticamente haciendo muy fácil determinar si una fase estaba en problemas o no.

Parte de esta hoja se llenaba automáticamente con información de otras bases de datos y algunas celdas permanecían disponibles para que el administrador del proyecto actualizara algunos valores de acuerdo con lo pactado esa semana (por ejemplo, un estimado podía variar si se autorizaba un cambio en el proyecto).

Al punto al que quiero llegar es que esta herramienta era todo lo que necesitábamos para llevar el seguimiento y para generar los reportes del avance del proyecto.

Con estas dos herramientas: un sistema de administración del portafolio y una hoja de cálculo, podíamos controlar la mayoría de la información que generaba el proyecto. Desde luego que, aunándolo a una buena aplicación para dar presentaciones y el SharePoint, nuestras necesidades quedaban satisfechas totalmente.

Además…

Actualmente poseo una licencia de un sistema llamado WBS Chart Pro y otra licencia del mismo proveedor (Critical Tools) llamada PERT Chart Expert. Ambas herramientas son económicas (199 USD cada una), muy fáciles de usar y proveen de posibilidades gráficas para representar las fases, entregables y actividades de un proyecto y su relación de jerarquía y dependencia integrándose ampliamente con Microsoft Project completando así una experiencia muy agradable y útil en la administración de mis proyectos.

Lo más importante es dominar tus herramientas

Quizás lo más importante dentro del vasto mundo de herramientas para un Líder de Proyectos sea dominar las herramientas cualesquiera que sean. Comúnmente entrevisto Project Managers que se pronuncian como usuarios intermedios de Microsoft Project y nunca han hecho un baseline, no saben forzar una relación finish-to-finish ni saben interpretar el reporte de Resources Usage que genera esa herramienta. No critico a tales individuos, solo quiero justificar mi comentario en el sentido de que necesitamos dominar al menos una herramienta a un nivel muy aceptable para que al momento de necesitar explotarla, esta nos proporcione lo que necesitamos sin mayores contratiempos. Mi esposa con frecuencia dice que “la tecnología debe trabajar para nosotros, porque una tecnología a la que hay que invertirle muchas horas para que haga lo que se supone que debe hacer, es una tecnología que no sirve, puesto que nos esclaviza y se supone que nosotros somos los amos y no los esclavos”. Estoy totalmente de acuerdo con esto en el sentido de que ya tenemos mucho de qué preocuparnos como para que la tecnología y las herramientas sean otro punto de preocupación.

Mi más atenta invitación a todos para adoptar sus propias herramientas y ponerlas a funcionar. Inviertan tiempo y dinero leyendo un buen libro que les muestre el funcionamiento total de la herramienta que hayan elegido, será tiempo y dinero bien invertido.

Por Fernando Valdez

Riesgos vs Problemas

Publicado el Mayo 31st, 2011 en Planeación, Riesgos, General por admin

risk-register.jpgHace ya muchos años fui asignado a un proyecto cuyo objetivo era desarrollar un sistema que integrara algunas pantallas de aplicaciones ya existentes dentro de un solo flujo de pasos, algo parecido a un workflow o wizard (aplicación que tiene diferentes etapas en las que el sistema recibe información y cuyo orden de captura es importante. También puede verse como una serie de pasos para completar una tarea), dado que los sistemas estaban desarrollados en plataformas diferentes pude anticipar que tendríamos algunos riesgos y problemas que resolver en su momento.

Ambiente del proyecto

Yo trabajaba en una compañía de telecomunicaciones que recientemente había comprado una compañía de TV por cable y tanto nuestros sistemas como los de la nueva compañía habían sido creados para plataformas tecnológicas diferentes .

Iniciamos el proyecto con dos desarrolladores y un analista  quien también participaba de las decisiones técnicas del proyecto. Por parte de la empresa cablera habían asignado a su mejor ingeniero, al de mayor experiencia y antigüedad y a dos de los mejores técnicos de sistemas quienes habían desarrollado su plataforma de aprovisionamiento de información.

Riesgos del proyecto

Por ser un proyecto pequeño decidí no formalizar mucho el ejercicio de identificación de riesgos, además, mi clara inclinación por pensar que el riesgo preponderante eran las múltiples plataformas tecnológicas que debíamos integrar nubló mi ejercicio de análisis y búsqueda de otro tipo de riesgos.

A esas alturas mi risk register contenía sólo un registro y el plan de mitigación no tenía pasos concretos a seguir para evitar, transferir o mitigar el riesgo.

Uno de los sistemas, el más importante, no pertenecía a la compañía en la que yo trabajaba, sino a la filial recién adquirida, así que los riesgos aumentaban en ese punto. Los miembros de la compañía de TV no estaban del todo contentos con la transacción de compra-venta y era claro que también estaban nerviosos (las bolsas de trabajo están llenas de curriculums vitae de empleados  descontentos y nerviosos por el futuro de su compañía).

Adicional a todo esto, las fechas que había establecido la dirección comercial eran muy agresivas, ya que el sistema sería utilizado para aprovisionar información de ventas en las diferentes plataformas para lograr tanto el registro de la información del cliente como la configuración del servicio recién vendido.

El problema

Para hacer más corto el relato, a la altura en la que estábamos haciendo las primeras pruebas de integración de las plataformas, el empleado más importante de la compañía de TV fue sacado del proyecto para atender asuntos pendientes urgentes de su compañía y los empleados de apoyo renunciaron.

La compañía cablera asignó dos ingenieros más al proyecto, pero éstos no conocían las plataformas con las que estábamos trabajando, de tal manera que se anticipaba una larga curva de aprendizaje.

El intento por resolver el problema

En ese momento mi issue log se llenó inmediatamente. La lista de problemas que se había registrado era interminable. Era imposible atender tantos problemas de alta prioridad al mismo tiempo con poco apoyo por parte del equipo técnico y con la presión del equipo ejecutivo quien ya estaba lanzando las primeras campañas publicitarias en las que le ponían fecha al lanzamiento del nuevo servicio “Triple Play” (Telefonía, Internet y TV por cable).

Fueron largas noches de trabajo las que invertimos para resolver todos los problemas que se generaron. La compañía de TV regresó al experimentado ingeniero al proyecto y eso favoreció mucho a la pronta resolución de los problemas.

Lecciones Aprendidas

Después de que la adrenalina bajó me puse a pensar, ¿por qué un proyecto que ciertamente presentaba reto se había convertido en un dolor de cabeza tan pronto? Debía haber una manera de prever los problemas que ocurrirían con cierta anticipación y no tan repentinamente.

Analizando encontré algunos defectos en mi manera de administrar el proyecto, principalmente el de no haber hecho un ejercicio adecuado de administración de riesgos.

La administración de riesgos supone la creación de un registro de riesgos, un análisis cualitativo y cuantitativo de los riesgos, una discriminación de aquellos poco probables de ocurrir o con poco impacto y la creación de planes de mitigación, transferencia o aceptación junto con un plan de contingencia para cuando ocurran.

Con lo anterior quiero decir que independientemente del tamaño y naturaleza del proyecto debemos hacer un análisis de los riesgos y registrar estos en un documento. No importa si el riesgo es pequeño o improbable, como líderes del proyecto necesitamos registrarlos.

Una vez establecido este documento al que llamamos risk register, es necesario analizar qué tan probable es que ocurran esos riesgos y, de hacerlo, cuál sería el impacto para el proyecto. Hay muchas técnicas para hacer esto, pero más bien quiero concentrarme en el siguiente paso que fue el que me provocó más problemas.

Hasta este punto un riesgo puede ser mitigado (reducido su probabilidad de ocurrir), evitado o aceptado, es decir, es posible planear maneras para que su impacto sea menor, su probabilidad sea menor o simplemente planear cómo vamos a afrontar los problemas que surgirán en el momento en el que ocurra.

Cuando un riesgo ocurre esto da lugar a problemas (issues) y es aquí donde tenemos que dejar de administrarlos dentro del registro de riesgos y empezar a manejarlos dentro del log de problemas para  resolverlos de acuerdo a los planes definidos de mitigación y respuesta .

El riesgo de perder a los ingenieros de la compañía de TV por cable se hizo realidad y yo ni si quiera lo había considerado en el risk register. Los problemas afloraron y yo no tenía planes de contingencia. Esto dio a lugar esfuerzos desmesurados, largas noches y descontento en el equipo.

Recomendaciones finales

Antes de terminar este post quiero hacer énfasis en un par de cosas. Aunque considero que dejé claro que hay que analizar todos los riesgos probables dentro de nuestro proyecto, esto no quiere decir que debemos planear como si todos fueran a ocurrir.

Debemos ser prácticos y planear sobre aquellos que son más probables de ocurrir y sobre aquellos cuyo impacto sería mayor en el momento de ocurrir. Por ejemplo, yo no me enfocaría en realizar planes de contingencia para un riesgo que tenga 0.05% de probabilidad de ocurrir y/o cuyo impacto nos obligue solamente a reemplazar un foco con valor de 0.50 pesos, pero definitivamente si registraría el riesgo a manera de documentación.

Otra cosa, los riesgos se administran como eventos probables de ocurrir y mientras haya tiempo para planear en acciones que los eviten o disminuyan, hay que hacerlo, es una inversión. Los problemas se administran como eventos que ya ocurrieron y se espera que se resuelvan de acuerdo con el plan de contingencias.

En resumen, en el mundo ideal no debería haber sorpresas en los proyectos. Los líderes de proyectos son contratados para llevar un proyecto a un término exitoso y con el menor número de sorpresas.

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.