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.

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 

Porqué es de suma importancia contar con una PMO

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

diverse_business_man_and_woman_40435468.jpg

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

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

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

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

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

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

outsourcing.jpg

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

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

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

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

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

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

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

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

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

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

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

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

Fernando Valdez

 

 
© 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.