Archive for Agosto, 2010

Líderes de Proyecto radicales

Martes, Agosto 31st, 2010

lider_radical.jpgHe conocido gente exitosa en el área de Project Management y puedo decir que todos comparten una característica en común: toman decisiones radicales en sus proyectos y no son indulgentes.

Permítanme explicar un poco mejor. Un administrador indulgente es aquel que es permisivo y laxo al perseguir sus metas. Traza planes pero frecuentemente pierde la visión original del proyecto. Permite que el ambiente y/o personas a su alrededor manejen la agenda o modifiquen el alcance de su proyecto. No estoy diciendo que un plan debe estar escrito en piedra, entiendo que para eso existen herramientas que nos permiten actualizar el “baseline” del proyecto y que por eso existe el concepto de “change process” dentro de la jerga de administración de proyectos, pero una cosa es administrar los cambios y otra es permitir que otros manejen su agenda y hagan los cambios que les parezca convenientes sin tomar la opinión del Líder del Proyecto.

Por el contrario, los administradores exitosos son personas flexibles al cambio y sensibles a las opiniones externas pero dejan muy en claro quién es el responsable del proyecto y en ocasiones toman decisiones radicales que pudieran parecer impopulares pero que favorecen el avance del equipo hacia la consecución de la meta original.

Hace poco experimenté las consecuencias de una decisión radical. Quisiera decir que yo tuve la iniciativa pero les estaría mintiendo, yo no tomé esa decisión; de hecho mi familia y yo sufrimos las consecuencias de esa decisión por más de un año y medio, pero al final pude extraer algunas lecciones de esa experiencia.

Experiencia

Trabajo para una compañía estadounidense que hace unos años se fijó una meta: ser una organización de 10 billones de dólares americanos para el año 2010. En ese entonces la compañía valía poco menos de 6 billones de dólares y la fecha trazada por nuestros propios ejecutivos se estaba acercando. La empresa recurrió a diferentes métodos para alcanzar su meta como lo fue la compra de otras compañías, la reducción de costos, la contratación de personal fuera de los Estados Unidos (off-shore), etc. Aún con estos esfuerzos la meta seguía lejana y fue allí cuando decidieron tomar una decisión radical.

En aquellos días yo era Project Manager de tecnología y pertenecía a un grupo reducido de empleados en México, pero los esfuerzos por alcanzar la meta de la compañía obligó a mi unidad de negocios a expandirse en México mientras reducía a su personal en Estados Unidos. Dado que una mayor cantidad de empleados demanda una administración más formal fui promovido a Administrador General de mi unidad de negocio para la oficina de México. Recibí el nombramiento y la carga de trabajo, pero en el momento en el que iba a recibir mi incremento de salario los ejecutivos de la compañía tomaron la decisión de congelar todo tipo de incrementos salariales con el fin de alcanzar la meta de los 10 billones de dólares. La cantidad de trabajo no se dejó esperar, las fechas límite empezaron a cumplirse y en pocos días yo estaba administrando una unidad de negocio mas allá del doble de lo que medía cuando yo era PM.

Todo creció… menos mi salario. Empecé a pensar que era injusto e incluso pensé que me habían engañado, que sólo me iban a dar la responsabilidad pero no el incremento. Confieso que en innumerables ocasiones busqué empleo en otras compañías y hasta busqué irme por la misma compensación que ya estaba recibiendo sólo con el objetivo de salirme de aquella compañía que no me había cumplido.

Mi jefe en Estados Unidos insistía en que quería retenerme y ya había conseguido la autorización (para mi incremento) de su jefe y del director ejecutivo de nuestra unidad de negocio, pero al parecer la orden de congelar los salarios venía desde mucho más alto.

Yo seguí trabajando y dando lo mejor de mí, no quería que nada influyera en la decisión de mi aumento una vez que los salarios fueran liberados, y a la vez ninguna oferta “allá afuera” era tan buena como la que tenía actualmente.

Un año después de congelados los salarios la compañía anunció que sería vendida a una compañía mucho más conocida que la nuestra. Para inicios de 2010 nuestra compañía había alcanzado su objetivo de ser una compañía de 10 billones de dólares (de hecho de 11 billones de dólares) y los incrementos de sueldo fueron liberados para todos aquellos que teníamos una promesa sobre la mesa.

En el proceso muchos buenos elementos salieron de la compañía porque no habían recibido lo que les habían prometido. En mi unidad de negocios ocurrió que uno de nuestros empleados “estrella” recibió una oferta y “amenazó” con salir de la compañía. Yo urgí a mi jefe para que hiciéramos algo porque no podíamos darnos el lujo de perder quizás al mejor elemento que teníamos, pero la respuesta fue negativa. Finalmente perdimos a un muy buen elemento y, en su momento, nos dolió profundamente, pero para ser franco debo decir que a la larga la pérdida que sufrimos no causó estragos en nuestra unidad de negocios y menos en nuestra compañía. Renunciamos a un bien menor por obtener uno mayor.

Decisiones radicales en Project Management

Hay proyectos que fracasan por cambios continuos en el alcance y nuestro rol como Líderes del Proyecto queda reducido a la de un coordinador de operaciones diarias que tiene que entregar reportes semanales de progreso y muchos más reportes relacionados con las operaciones del equipo de trabajo.

Nuestra labor diaria debería incluir la toma de decisiones radicales en beneficio del proyecto. Debemos saber tomar decisiones radicales con respecto al presupuesto, con respecto al alcance y con respecto al tiempo de entrega. Estas decisiones pueden ser impopulares de momento, pero es lo único que nos puede ayudar a concluir nuestros proyectos de la manera planeada.

Para cumplir los hitos (milestones) del proyecto necesitamos ser radicales en el uso del proceso de aceptación de cambios (change request process), necesitamos ser radicales en la entrega a tiempo. Necesitamos aprender a negociar y a congelar los cambios solicitados y aprender a versionar nuestros productos.  Se requiere saber decir “no”. Se requiere saber decir “hasta aquí”.

Si tomamos decisiones radicales es probable que algún entregable quede fuera del alcance del proyecto y es probable que haya uno o dos patrocinadores molestos con nuestras decisiones, pero el objetivo del proyecto (que ellos mismos están patrocinando) se habrá cumplido en los términos solicitados y podrán empezar a recibir sus beneficios.

Principios para la toma de decisiones radicales

Quiero compartir algunos principios para tomar decisiones radicales pero racionales que ayuden a la consecución del objetivo de sus proyectos:

  • Necesitamos entender que cualquier proyecto es importante. No necesita ser el proyecto más grande de la compañía para esforzarnos por terminarlo en forma. Si somos indulgentes en lo pequeño, lo seremos en lo grande.
  • Necesitamos aprender a decir “hasta aquí” y “no” de manera amable. No tengas miedo a tomar decisiones “muy sonoras” o impopulares siempre que un análisis costo-beneficio te dé la razón.
  • Si eres el Líder de un proyecto y no puedes decir “hasta aquí” en realidad no eres más que un “chivo expiatorio” al que le pueden echar la culpa cuando el proyecto fracase. * * Haz que los ejecutivos o los clientes firmen un Project Charter en el que se te otorgue la responsabilidad del proyecto, pero también la autoridad de tomar decisiones que beneficien al proyecto.
  • Probablemente vaya a haber “bajas de guerra” pero no te acobardes. El miedo no es razón para cederle terreno al fracaso. Antes de tomar una decisión radical haz un análisis “What if…” donde consideres los mejores y los peores escenarios y una vez tomada la decisión llévala hasta el límite: alcanzar el objetivo.

Conclusión

No conozco ningún gran logro que se haya hecho sin esfuerzo ni ningún proyecto exitoso en el que no haya habido necesidad de ser radicales con respecto al alcance y/o al tiempo. No conozco un logro importante que no haya involucrado el trato con gente y en ocasiones hasta confrontación del Líder del Proyecto con más de uno de los interesados en el proyecto.

Pensar alcanzar una gran meta sin esfuerzos ni confrontaciones es ingenuo.

Por Fernando Valdez

No siempre decirle que sí a todo lo que diga un director, sin antes evaluar la situación

Miércoles, Agosto 4th, 2010

fmu.jpg¿Quien dijo que aprendemos solamente de las grandes y complejas experiencias? Los niños aprenden todos los días algo nuevo con lecciones sencillas de vida. Durante muchos años asistí a seminarios, pláticas y presentaciones relacionadas con mi profesión y puedo decir que las lecciones que más me sirvieron fueron aquellas que cubrían las cosas cotidianas, aquellas con las que seguramente me iba a enfrentar más temprano que tarde.

Recuerdo que mi padre, siendo médico profesor de postgrado con una alta especialización, me recomendaba: si enseñas en un grupo de setenta alumnos y dentro de ese grupo tienes dos “genios” no cometas el error de enseñar al nivel de los “genios” sino de los 68 “mortales”; los “genios” ya se toparán con un profesor suficientemente inexperto como para lucirse enseñándole a esos dos “genios” y dejando 68 alumnos sin adquirir conocimientos.

Dicho esto, quiero comentar una experiencia que seguramente le ha ocurrido a muchos Líderes de Proyecto, pero de la que obtuve mucha experiencia.

Descripción del proyecto

Nos encontrábamos a punto de arrancar el desarrollo de una aplicación Web que serviría para administrar integralmente la información de cobranza de la compañía;  el sistema contabilizaría los intentos de llamada para contactar a los clientes y registraría los acuerdos hechos con los mismos para el pago de sus cuentas pendientes con nosotros. La información de los clientes la recibiríamos de un sistema externo y la cargaríamos a nuestro sistema en un proceso diario.

Ambiente del proyecto

Por el lado del negocio había un gerente de Crédito y Cobranza (CyC) que definiría el alcance y la funcionalidad deseada en el sistema. Este gerente le reportaba al Director de Finanzas de la compañía quien era un director joven, muy versado en temas de tecnología y que gustaba de involucrarse en los detalles de cada una de las gerencias a su cargo. No solo daba el rumbo que debían seguir las gerencias sino que se involucraba al nivel de los proyectos hombro con hombro con sus gerentes. Este director gozaba de la reputación de “lograr lo que se proponía”.

Desarrollo del proyecto

En aquel momento mi equipo estaba trabajando en la fase final de un proyecto de mayor prioridad, tan pronto como ese proyecto fuera concluido iniciaríamos el proyecto de CyC . Sin embargo, las actividades el proyecto actual nos permitían empezar a explorar algunos aspectos del negocio del siguiente proyecto, de tal manera que empezamos contactando al gerente de CyC y tuvimos varias reuniones para analizar los procesos del negocio e incluso llegamos a hacer un diseño básico de los entregables para validar el alcance. Desarrollamos algunos casos de uso, diagramas de flujo de datos y habíamos esbozado algunas pantallas tentativas para el sistema.

Problema

Las actividades que estábamos realizando dieron la impresión de que ya estábamos abordando el proyecto de CyC de lleno, pero no era así. Un día, cerca de haber terminado el análisis y de haber empezado el diseño inicial, fui llamado a la oficina del director de finanzas mientras el tenía su junta semanal de status de sus gerentes. Cuando entré en la oficina escuché como el director de finanzas daba muchos detalles y hacía muchas preguntas con respecto al diseño de la aplicación que desarrollaríamos para ellos y pude percibir que el gerente de CyC estaba pasando un mal rato mientras recibía cambios en el diseño original de la aplicación; habían llegado al punto en el que el gerente no podía dar más detalles y entonces me llamaron para ver si todos esos cambios eran factibles y para conocer más acerca de la implementación.

En algún momento de la plática mencioné que aún estábamos analizando, pero el director, con su amplia experiencia para obtener resultados, esbozó un alcance para la aplicación (pasando totalmente por encima del gerente quien ya no proponía ni negociaba), y terminó su intervención preguntando: “Con este alcance, ¿cuando crees poder mostrarnos los primeros avances?”. Con mi experiencia en el área de desarrollo de sistemas medí el esfuerzo y contabilicé a groso modo las duraciones en bloques semanales, y sin pensarlo mucho mi precipitada respuesta fue: “Si iniciamos a finales de Agosto, seguramente podremos ver los primeros entregables a mediados de octubre”. El director complacido agradeció mi presencia en su oficina y me retiré.

A mediados de octubre el director de Finanzas estaba llamándome para pedir una presentación del sistema y la realidad es que a esas alturas estábamos apenas terminando el análisis. Las palabras del director, entre tantas otras que dijo, fueron “…pero tu me dijiste que terminaban a mediados de octubre…”.

Análisis del problema

Teníamos un portafolio de proyectos que íbamos abordando conforme a las prioridades dictadas por la dirección general y nosotros nos encontrábamos concluyendo un proyecto de mayor prioridad que el de aquel director.

La fase en la que se encontraba el proyecto de mayor prioridad nos permitía ir explorando futuros proyectos, pero no habíamos  iniciado formalmente el proyecto del director de finanzas.

Teníamos frente a nosotros a un directivo de alto nivel con amplia experiencia para lograr lo que deseaba, era natural que intentara obtener un compromiso de mi parte para terminar su proyecto cuando él lo necesitara, sin importarle las prioridades de las otras líneas del negocio.

El ambiente de aquella oficina no era el adecuado para definir el alcance y mucho menos prometer una fecha de entrega.

Siguientes acciones

Una de las actividades más importantes y que resume muchas de las tareas que un líder de proyectos hace día con día es eliminar toda ambigüedad del proyecto. Somos contratados y recibimos una paga para orquestar el cumplimiento de los proyectos y para reducir a cero toda ambigüedad tanto para los que fabrican el producto como para los inversionistas. Dar una fecha no fue lo más sabio.

Mas adelante tuve que hablar con el director aclarando que estábamos terminando un proyecto de mayor prioridad y que apenas estábamos iniciando el desarrollo del suyo. Le comenté que ni siquiera habíamos empezado formalmente su proyecto y que lo que había ocurrido aquel día en su oficina fue una discusión informal y que el alcance no había sido registrado ni estimado sino hasta después con ayuda de su gerente de CyC.

Esta plática dejó un mal sabor de boca y me dejó mal posicionado a mí y a mi equipo a pesar de que fue el director quien empujó las cosas para que ocurrieran así. Pero fue la inexperiencia y la presión del momento los factores que me hicieron entrar en su propio juego.

Lecciones aprendidas

En esa reunión el indicado para dar cuentas del proyecto era el gerente de CyC. Se trataba de una junta del departamento de finanzas, no de la Oficina de Proyectos (PMO).  El líder de proyecto tiene la obligación de rendir cuentas a quienes se haya definido en el plan de comunicaciones.

Si te preguntan el status de un proyecto, puedes remitirlos al último reporte de avances enviado y mencionar algunos de los logros alcanzados hasta ese momento y puedes mencionar que ya estás trabajando en el siguiente reporte en el que les harás saber el status más reciente de los avances.

Si, como fue mi caso, te preguntan el status de un proyecto que no ha dado inicio formalmente, puedes simplemente comentar eso y mencionar que solamente estás haciendo labor de investigación previa para ganar un poco de tiempo (lo cual les conviene a ellos).

Los requerimientos nunca se toman en el pasillo ni en el elevador ni durante una junta con otro propósito. Esta es una manera de decir que un requerimiento para cualquier tipo de proyecto debe ser registrado como parte del alcance sólo en reuniones establecidas para ese propósito, lo contrario llevará a desorden y ambigüedad.

Se pueden explorar otros proyectos antes de comenzarlos formalmente, pero nunca dar la impresión de que ya se ha iniciado el proyecto. Desafortunadamente en muchos países se acepta arrancar un proyecto sin una reunión de “kick-off” formal. Necesitamos cambiar eso, puede ser una reunión de 30 minutos con todos los involucrados posibles en la que se establezca que el equipo de proyecto formalmente dará inicio al análisis y estimación del proyecto en turno. Finalmente vale la pena enviar una minuta a todos los presentes Y a los ausentes a la junta de arranque de proyecto.

Normalmente en organizaciones con estructura funcional rígida un director tendrá la posibilidad de llamarnos a su oficina y pedirnos algunas explicaciones. No se trata de evadir esa responsabilidad, pero si de controlar lo que vamos a decir. Sugiero nunca dar fechas antes de tener un cronograma formal del proyecto. Si somos empujados a dar fechas, podemos “jugar” con duraciones, es decir, podemos mencionar: “el alcance que estás sugiriendo puede tomar alrededor de 6 semanas para ser desarrollado, pero eso lo vamos a saber después de las fases de análisis y diseño del proyecto”.  Con esto no estamos comprometiendo fechas de arranque ni de término. Si el director se ve tan hábil como para decir “ok, estamos a fines de agosto, eso quiere decir que terminarán por allá de mediados de octubre” nosotros podemos simplemente decir “en teoría sí, pero la realidad es que no podemos arrancar el proyecto el día de hoy porque tenemos otras prioridades”, y podemos enviarlo a hablar con el director de nuestra PMO o de nuestro departamento para que discutan las prioridades de los proyectos pendientes.

Hoy en día puedo ver cómo Administradores de Proyectos inexpertos caen en esos errores y se encuentran abrumados en actividades y explotando a los miembros de su equipo para terminar un compromiso imposible. Su inexperiencia en eliminar ambigüedades los han puesto a “bailar al son” de los ejecutivos de la organización quienes presionaron a dar “fechas felices” sin un sustento técnico válido.

Las prioridades las pone el negocio, la labor del Administrador de Proyectos es asegurarse que el equipo de proyecto fabrique los entregables en el tiempo estipulado (después de una estimación adecuada), bajo las normas de calidad establecidas en el plan de calidad y dentro del presupuesto asignado para el proyecto (considerando cualquier cambio introducido por el negocio mediante un adecuado control de cambios que impacte el presupuesto, alcance y tiempo).

El director tuvo su sistema pero no le gustó… desafortunadamente para él, después de aquel error que cometí, me dediqué a documentar los detalles del diseño del sistema y me aseguré de solicitar su autorización (con su firma impresa) para todos los cambios y sugerencias que nos había hecho.

Por Fernando Valdez