Al reflexionar sobre mi trayectoria como gerente de proyectos, recuerdo una oportunidad en la que apliqué las lecciones aprendidas en la Parte 1 y, con algunos riesgos, guié a la organización para que se alejara de lo que yo creía que era una idea errónea y la orientara hacia una óptima. Espero que este artículo les brinde información útil que puedan aplicar en situaciones similares.
Un día, en esta empresa, recibí una llamada del asistente personal del CEO, quien me pidió que lo acompañara junto al Director de Operaciones a una visita externa al día siguiente. No recibí más detalles, así que me uní a ellos para visitar una conocida empresa de externalización de Tecnologías de Información (TI). Durante la reunión, la empresa mostró sus amplias capacidades de TI. Supuse que mi inclusión se debía a una importante interrupción de TI ocurrida unos meses antes, durante la cual había organizado uno de los equipos de respuesta para gestionar las operaciones durante la emergencia con nuestros principales sistemas.
Durante la reunión, me limité a observar y a escuchar atentamente, dado que no me habían informado sobre mi función en ella. A primera vista, la propuesta de externalizar completamente nuestras operaciones de TI parecía un buen plan: prometía operaciones de TI «tranquilas» mediante la externalización de todos nuestros servidores, datos y personal de TI. Sin embargo, identifiqué un punto que, para mí, constituía una falla crítica: como parte de este plan, se externalizarían nuestros sistemas y datos esenciales. Si bien coincido en que la externalización puede generar numerosos beneficios, creo que no se debe renunciar al control sobre las operaciones críticas.
A nuestro regreso, pregunté por qué me habían invitado. El CEO y el COO respondieron que planeaban externalizar todas las operaciones de TI y querían que yo liderara el proyecto de migración. Consideraban que el actual gerente de TI, que estaba próximo a jubilarse, no era la persona ideal para el puesto y que mi intervención durante la emergencia de TI mencionada anteriormente me posicionaba como el mejor candidato para liderar esta migración.
Les agradecí su confianza, aunque expresé importantes reservas sobre este plan. Reconocí los beneficios de externalizar la mayoría de las funciones de TI, pero enfaticé que los datos principales y los procesos críticos debían permanecer internos a la empresa, bajo nuestro control. Les aseguré mi compromiso de liderar dicho proyecto de migración, siempre que mantuviéramos el control de las operaciones esenciales. Al decir eso, arriesgué mi trabajo, ya que mi contrato permitía una rescisión fácil y sin complicaciones. Pero la experiencia me había enseñado a decir que no y defender a tiempo la decisión correcta y así no arrepentirme después.
Mi respuesta sorprendió al CEO y al COO, quienes respondieron que necesitaban tiempo para considerar mis objeciones. Dos días después, el CEO me informó que lo habían reconsiderado y habían decidido abandonar por completo el plan de externalización de TI. Unos meses después, fui ascendido a director del departamento de TI tras la jubilación del anterior director. Esto marcó una etapa muy gratificante en mi carrera, trabajando con un equipo profesional y motivado que aportó un valor sustancial a la organización.
A lo largo de mi carrera, me he encontrado con numerosos casos en los que clientes (tanto internos como externos) solicitaron enfoques que yo sabía que eran defectuosos. Cada vez que había cedido a tales solicitudes, las cosas habían salido mal, a veces terminando en un atolladero.
Por lo tanto, ante solicitudes similares, les insto a que lo piensen dos veces y se esfuercen por guiar a sus clientes hacia las opciones de proyecto correctas. Un liderazgo eficaz a menudo implica defender lo que uno sabe que es mejor, incluso si implica asumir riesgos personales.
Deja una respuesta