En todos los años que vengo trabajando, me he enfrentado a la realización de proyectos desde distintos roles: como la persona que plantea un proyecto, como la persona designada para ser líder de un proyecto, como la key user de un proyecto, o como la persona que debe utilizar el resultado de un proyecto.

Desde estos roles (sumado a la especialización en gestión de proyectos que llevé en el 2016 y a mi certificación como Scrum Master en el 2017) es que he podido aprender una serie de lecciones que quiero compartirles a continuación:

1. Los proyectos no deberían nacer de caprichos sino de necesidades reales de usuarios: «Si mi competencia lo tiene, yo también debo tenerlo». No sé hasta qué punto esa frase sea aceptable, quizás si quieren ser fast followers (a veces ni siquiera tan fast) toda la vida, pero si quieren ser pioneros en la industria tienen que ver más allá de lo evidente e «innovar» (esa palabra que está tan de moda). Ojo que innovar no es adquirir un nuevo software e implementarlo o comprar nueva maquinaria, innovar va mucho más allá. Es un proceso que consiste en identificar necesidades reales de usuarios (internos o externos a la organización), definir cuál es reto / dolor / insight que se quiere resolver, idear una serie de soluciones potenciales para luego escoger algunas, testearlas en el mercado, recibir feedback, iterar hasta que tenga la aceptación esperada y finalmente lanzar la solución.
2. Aceptar gestionar un proyecto solo/a es suicida: si les vienen a decir cosas como: «eres un talento para la organización y hemos visto potencial en ti para gestionar un proyecto estratégico» pero no les dicen nada de que les van a dar un equipo para gestionar el proyecto o un mínimo de presupuesto para poder hacer algunos cambios o lograr algunos hitos, TENGAN MUCHO CUIDADO!!! Los proyectos empresariales requieren un sponsor, trabajo en equipo, diversidad de habilidades, capacidades y puntos de vista, y algo de presupuesto, para llegar a los resultados esperados. Yo hace unos 2 años acepté un proyecto bajo estas condiciones: 1) porque parte de mi filosofía de vida profesional es aceptar todos los retos que me propongan y dar el 500% para lograrlos y 2) porque el tema del proyecto me parecía super interesante: era algo que si bien se trató de implementar antes en la organización, no tuvo el resultado esperado, y yo pensé que era la oportunidad perfecta para lograr lo que nunca antes se había logrado. En esa época creo que fui bastante ingenua por no profundizar un poco más en el alcance y los recursos que necesitaría para llevar a cabo lo que se esperaba del proyecto, pero estaba enceguecida por la adrenalina del reto encomendado y me juré la Mujer Maravilla. Lección aprendida, cada vez que me piden un nuevo proyecto lo primero que pregunto es por el equipo y el presupuesto. En base a esas respuestas es que yo puedo estimar si el alcance que me proponen es realista, o si vamos a tener que ajustar el alcance o meter la mano al bolsillo y sacar algo de presupuesto. Los Gerentes deben entender que por más talentosa que sea una persona y por más que se saque la mugre por el proyecto, no va a llegar a ningún lado sola. Más es la frustración e impotencia que le va a generar no obtener los resultados esperados, pero no es su culpa, ya que ningún proyecto se hace bien con un hombre o mujer orquesta. Y esa frustración puede llevar a sus colaboradores estrella a renunciar.
3. Los proyectos no se pueden encargar como «favores»: en línea con el punto anterior, cuando les hablen bonito del tema de que son talentos y que por eso han pensado en ustedes, etc. también tienen que marcarles la cancha y decirles claramente cuál es el propósito del proyecto (¿por qué vamos a hacer esta chamba?), qué objetivos esperan que alcancemos como líderes de proyecto (¿qué tenemos que lograr con esta chamba?) y qué indicadores debemos cumplir (¿cómo nos van a medir al final de la chamba?). Y hablando de indicadores, los indicadores del proyecto deberían ser transversales para los miembros del equipo. De nada sirve que ustedes se rompan el lomo por alcanzar los indicadores si sus equipos no sienten ese mismo sentido de urgencia y ven al proyecto como la última de sus prioridades. Otras preguntas que deberían hacerle a las personas que les encarguen proyectos es si ya hablaron con sus jefes directos sobre este tema (obvio que sus jefes tienen que estar informados que van a hacer chamba extra) y cómo los resultados de este proyecto se ven relacionados con sus objetivos de desempeño o perspectivas de crecimiento en la organización, ya que todo el esfuerzo que vamos a realizar como líderes de proyecto, debe ser reconocido del alguna forma.
4. Querer acelerar un proyecto sin ampliar el costo, los recursos o reducir el alcance es prácticamente imposible: «Te acuerdas que acordamos acabar este proyecto en diciembre, pues bueno voy a necesitar que se adelante a setiembre, pero dada la coyuntura del negocio no vamos a contratar a nadie más o ampliar el nulo presupuesto que te hemos asignado». ¿Esta frase les suena familiar? Los gerentes deben entender que si quieren acelerar un proyecto deben escoger 2 de las 3 B: Bueno, Bonito y Barato. Según lo que recuerdo del diplomado en gestión de proyectos, las formas de acelerar un proyecto son:
   • Fast tracking: modificar las relaciones entre tareas para que dos actividades que se ejecutaban una después de otra, ahora se ejecuten en paralelo, siempre y cuando la relación entre tareas no sea obligatoria (condición sine qua non) ¿Cómo se logra esto? Contratando más gente interna o terceros ¿Qué pasa cuando haces esto? incrementas el riesgo, el costo y la necesidad de recursos.
   • Crashing: reducir el tiempo de ejecución de una tarea sin modificar el alcance de la misma.  ¿Cómo se logra esto? aumentando la eficiencia de los recursos, la cantidad de recursos asignados y creando procesos de trabajo más eficientes en base a las lecciones aprendidas ¿Qué pasa cuando haces esto? incrementa el riesgo, el costo y la necesidad de recursos (¿les suena familiar? sucede lo mismo que en la estrategia anterior)
   • Modificar el alcance de las tareas: Reemplazando las tareas existentes por otras más rápidas de hacer que obviamente no van a tener el mismo resultado ¿Qué pasa cuando haces esto? incrementa el riesgo y el costo, ya que les puede salir el tiro por la culata
   • Ajustar la gestión de riesgos o reducir la calidad: en ambos casos también puede salir el tiro por la culata: si se hacen los de la vista gorda frente a un riesgo del proyecto o si reducen los controles de calidad de un entregable para que se pase más rápido a la siguiente actividad.
   • Reducir el alcance: Esta ya es la última opción, cuando no se va a poder considerar más gente o más presupuesto o no se quieren hacer los de la vista gorda con los riesgos y la calidad, lo único que queda es ser realista y modificar el alcance del proyecto, lo cuál obviamente puede generar insatisfacción de los stakeholders del proyecto. Caballero nomás!
5. Si algo le funciona a una empresa de un rubro parecido al suyo, no necesariamente va a funcionar con ustedes: «Pero si este software ha funcionado en las empresas A, B y C que también son empresas industriales como nosotros». Lo que no saben es que quizás las empresas A, B y C les llevan años luz en temas de planificación, modelos de gestión, estrategias de crecimiento, etc. O quizás su cultura organizacional impulse más la ejecución de proyectos que la de ustedes. ¿Su gente está comprometida?, ¿tienen una cultura de accountability o tienen que perseguir a su gente para que las cosas sucedan?, etc. Hay que ser lo suficientemente conscientes y sensatos para darnos cuenta que la organización no está en el momento ideal para implementar un proyecto y que cualquier esfuerzo o presupuesto asignado al proyecto va a ser una pérdida de recursos. No nos debemos encaprichar con un proyecto (volver al punto 1).
6. Lo que se ve bonito en una demo o en una feria quizás no se vea igual en sus empresas: «Pero si en el vídeo de la consultora se veía como una herramienta increíble que nos iba a hacer la vida más fácil». Cómo dicen «todo entra por los ojos» pero no se puede ser tan ingenuo para creer que tal cual como lo vendieron va a quedar en la empresa sin el esfuerzo respectivo. La verdad es que si nos venden algo (por ejemplo, las consultoras de software siempre presentan vídeos y demostraciones alucinantes con mil funcionalidades) debería quedar igual en nuestra organización, pero si obtener ese resultado depende un grupo de personas que no entienden el propósito de dicha implementación y no están comprometidas con el cambio porque creen que es más chamba al mismo precio, quizás el proyecto no llegue a buen puerto. Otro punto importante a analizar es en qué momento de madurez se encuentran sus empresas. Quizás se encaprichan en comprar un Ferrari cuando su gente apenas sabe manejar bicicleta.
7. Un proyecto sin sponsor está destinado al fracaso: si no hay una persona de alto rango que auspicie los proyectos, que apruebe los recursos, que «corte el queque» cuando se necesite y que conecte con los gerentes y CEO de la empresa, lo más probable es que sus proyectos no tengan éxito, porque cada gerente va a tener sus propias prioridades y sin un sponsor, sus proyectos no van a aparecer ni siquiera en sus agendas. Recuerdo que en un proyecto transversal a la organización que lideré hace unos 4 años, el sponsor y principal interesado era el CEO y todos los meses nos reuníamos con todo el Comité Ejecutivo para presentar los avances y resultados. Lo que sucedía en varias oportunidades, es que acabada la reunión yo enviaba el acta, y los responsables de las actividades no le prestaban mucha atención hasta el día anterior a la reunión cuando se ponían las pilas porque sabían que el CEO iba a estar presente en la reunión de seguimiento. Obviamente no es que yo dejara a los responsables de las actividades a la deriva durante un mes, pero ¿hasta qué punto un Project Manager debe actuar de «niñera» para que las cosas sucedan y se cumplan los tiempos? Quiero pensar que dejaban todo para último minuto porque tenían otros temas urgentes y no porque no les interesara el proyecto o no fueran accountables con sus responsabilidades.
8. Si un proyecto nace mal, lo más probable es que muera antes de obtener resultados: Esto sucedió en un proyecto que tratamos de implementar y lanzar hace más de 4 años (y que hasta el momento sigue sin tener los resultados esperados y se le sigue metiendo billete). Se trataba de un software de CRM que algunos gerentes pensaron que iba a ser la maravilla en gestión y relacionamiento con los clientes y que habían visto la demo y que todas las funcionalidades nos servían (ver punto 6), y que se había implementado en otras empresas industriales (ver punto 5), y que nosotros seríamos los pioneros en nuestro rubro en implementarlo, etc, etc, etc. Pero creo que lo que faltó antes de invertir un sólo dólar fue levantar las expectativas de los principales usuarios: entender cuáles eran sus funciones, cómo hacían su trabajo, en qué herramientas se apoyaban, etc. No se supone que la empresa se tiene que adecuar a la herramienta (porque eso es fracaso asegurado), sino que la herramienta debe facilitar la forma en la que se hace el trabajo. Quizás si los principales responsables del proyecto se hubieran tomado la molestia de hacer este levantamiento (y si lo hicieron entonces no entiendo cómo decidieron continuar con la implementación), hubieran llegado a la conclusión de que no era el momento adecuado para implementar un CRM en la organización y que quizás la marca de CRM que tenían en mente no era la más adecuada para la empresa. Pero si, hipotéticamente hablando, este proyecto nació de un capricho de algunos gerentes, entonces ellos deberían leer el punto 1.
9. La gestión del cambio no es floro, realmente importa: la cultura de sus empresas puede matar un proyecto sin que se den cuenta, y eso es parte de lo que está pasando con el proyecto de CRM del punto anterior. Si bien como parte de la metodología de gestión de ese proyecto hubo talleres de gestión del cambio: 1) se hicieron muy tarde (cuando el proyecto ya estaba avanzado) y 2) fueron de esos talleres que se hacen por obligación y que lo que se dicta le entra a la gente por un oído y les sale por el otro. La gestión del cambio debe ser un proceso constante, monitoreado a lo largo de toda la implementación del proyecto, y tener un sistema de alertas en caso se vea que las cosas no van de acuerdo a lo esperado. Además, debe partir del compromiso consciente (y no sólo para la foto) de los líderes de la organización, quienes deben predicar con el ejemplo. Una de las frases que escuché durante este proyecto fue: «si mi jefe no usa la herramienta, ¿por qué yo debería utilizarla?». 
10. Las metodologías no están escritas en piedra, se pueden (y hasta deben) tropicalizar y fusionar: Finalmente, hace un par de semanas me encargaron gestionar un grupo de proyectos y me pidieron que fusione la metodología tradicional de gestión de proyectos con el marco de trabajo Scrum. Y lo que hice fue analizar el contexto de los proyectos y de los líderes de los mismo, y ver qué buenas prácticas de cada una de estas formas de gestión de proyectos puedo aplicar (como diría Hannah Montana, the best of both worlds, sorry se me sale lo millennial). Hay que ser lo suficientemente flexibles para entender que no debemos aplicar todos pasos o los formatos a rajatabla, sino que debemos aplicarlos según creamos conveniente, ya que para eso tenemos el criterio y el conocimiento del negocio que nos permitirá saber qué aplicar en cada fase. Y si algo no funciona a la primera, nos tocará analizar qué salió mal, pivotear e iterar hasta llegar al modelo de gestión adecuado. Al fin y al cabo, fusionar metodologías de gestión de proyectos es una forma de innovación en procesos.

Si tienen más lecciones aprendidas, no duden en dejar sus comentarios!!!