Andares de un proyecto

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.