He 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.
No siempre decirle que sí a todo lo que diga un director, sin antes evaluar la situación
¿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.
Conocer el detalle del árbol sin dejar de pensar en la perspectiva del bosque es importantísimo, de lo contrario puedes andar dando tumbos perdido en las particularidades, olvidando cumplir los objetivos realmente importantes del proyecto.
Se acerca la entrega del proyecto, los días han sido intensos como bien saben, llegar temprano, salir tarde, descubrir que hay muchas actividades que no se realizaron y entregables que no están listos, más otra infinidad de cosas que no se entendieron de acuerdo a la especificación, debo confesar que en este proyecto entré a ocho meses de iniciado.
¿Cómo motivar a un equipo de trabajo? hay varias técnicas, pero considero una la más importante: Sentirse útil, saber que el trabajo que se realiza soluciona problemas, pocas cosas son tan gratificantes como un buen trabajo realizado.
El tic-tac del reloj sonaba con la fuerza que uno percibe después de una noche de vigilia, sólo el cálido sabor del café y el frío del alba me mantenían despierto. Tenía razón ese viejo lobo de los proyectos que me recomendó en cada desvelo, subir a la azotea y contemplar el amanecer al menos durante media hora para reflexionar y recapacitar sobre el rumbo del proyecto.
