El riesgo que vino del sótano

Dicen que los proyectos de tecnología no son para los débiles de corazón. Yo digo que tampoco lo son para los que duermen bien por las noches.
Era un martes. Porque, como todo lo malo en la vida, siempre empieza un martes. Estábamos arrancando el despliegue de una nueva plataforma para un cliente. En la reunión de KickOff, todos sonreían como en anuncio de café: el sponsor comprometido, los stakeholders alineados, el equipo técnico con estrellas en los ojos y los PMs, bueno… los PMs haciendo lo que mejor sabemos hacer: cruzar los dedos por dentro mientras proyectamos confianza por fuera.
Todo iba bien. Hasta que no.
Capítulo 1: El riesgo fantasma
A la segunda semana, el equipo técnico nos menciona algo así como:
“Solo es un pequeño issue de compatibilidad con el sistema… pero nada grave.”
Nada grave. Esa frase debería estar prohibida en los proyectos. Debería sonar una alarma cada vez que alguien la dice. Porque ese “pequeño issue” era un riesgo dormido, uno de esos que no aparecían en la matriz de riesgos base. Nadie lo había registrado porque "no se esperaba que impactara". Claro. Como el meteorito que no iba a caer.
Dos semanas después, ese "issue" se convirtió en un Frankenstein que impedía la migración. El cronograma empezó a sangrar días, el cliente comenzó a sudar dudas y nosotros a escalar el riesgo como quien grita "¡FUEGO!" en una sala de cine.
Capítulo 2: Escalar o no escalar… esa es la cuestión
Fue entonces cuando descubrimos que escalar un riesgo no es tan fácil como decir “¡Houston, tenemos un problema!”. Porque antes de eso viene el ballet diplomático:
Hablas con el líder técnico.
El líder técnico habla con el proveedor.
El proveedor dice que necesita un parche que aún no está en QA.
QA dice que están en cierre.
Y tú, el PM, estás en cierre emocional.
Decidimos elevar el riesgo oficialmente en Steering Committee. ¿La reacción? Un silencio tan profundo que se podía escuchar cómo envejecía el plan de proyecto. Hasta que el sponsor preguntó:
“¿Y por qué no se anticiparon a esto?”
Touché.
Capítulo 3: El club de los PMs que lloran en silencio
En una de esas reuniones donde el café se acaba, pero los problemas no, mi colega un PM con más cicatrices que un Jedi jubilado, me dijo: “A veces, los riesgos son como cucarachas. Si ves una, probablemente hay veinte escondidas. Lo importante es aprender a prender la luz a tiempo.”
Esa frase se me quedó grabada. Porque lo cierto es que habíamos subestimado ese riesgo. Y no porque fuéramos irresponsables, sino porque, como muchos, caímos en la trampa de "esto no ha pasado antes, así que no pasará ahora".
Pero la gestión de riesgos no es predecir el futuro con una bola de cristal. Es tener el coraje de pensar en todo lo que podría salir mal y planear como si ya estuviera pasando.
Capítulo 4: El PM que aprendió a amar la matriz base de riesgos
Así fue como la matriz de riesgos dejó de ser un documento olvidado en la carpeta “Documentación Obligatoria” y se convirtió en nuestro mapa del tesoro (con minas activas). Empezamos a hacer sesiones semanales de identificación de riesgos, involucramos al equipo técnico, al cliente y hasta al practicante que una vez soñó que el servidor explotaba.
Teníamos post-its, matrices de impacto/probabilidad, y un semáforo que nos recordaba que el rojo no es un color decorativo.
También aprendimos a distinguir entre riesgo identificado y riesgo gestionado. Porque apuntarlo es solo el primer paso; lo importante es tener un plan B, C, y en algunos casos, Z (como "Zafarnos de este lío sin morir en el intento").
Capítulo 5: El final… o eso creíamos
Finalmente, logramos mitigar el Frankenstein con una solución híbrida. No fue elegante, pero fue efectiva. Perdimos unas semanas, sí, pero salvamos el proyecto. Y lo más importante: recuperamos la confianza del cliente, quien al final del UAT nos dijo:
“Fue duro, pero se notó la gestión. Se notó que no dejaron el barco solo en la tormenta.”
Y aunque yo ya me había comido las uñas y parte de las cutículas, sonreí como si todo hubiera estado bajo control. Porque eso también hacemos los PMs: actuamos como cisnes serenos… mientras debajo del agua estamos pedaleando como locos.
Empezamos a planificar la entrega final, la retrospectiva y por supuesto, el after office con cerveza en mano. Todo indicaba que el proyecto iba a cerrar con un moño dorado.
Pero entonces llegó el correo.
Asunto: Repriorización de iniciativas estratégicas – Acción requerida
El área de negocio había cambiado de dirección. Nuevas prioridades, nuevos focos. La plataforma que acabábamos de implementar, con todo su sudor y lágrimas, quedaba en modo piloto indefinido. El presupuesto se reasignaba. Y lo que había sido un proyecto estrella… se convirtió en una constelación olvidada.
Nos quedamos en silencio, otra vez. Pero esta vez fue distinto. Esta vez, entendimos que hay riesgos que no están en la matriz de impacto/probabilidad. Riesgos que viven en los pasillos de la organización, en PowerPoints de alta dirección, en cafés entre ejecutivos.
Epílogo: El verdadero riesgo
El proyecto cerró. No mal, pero tampoco como esperábamos. Lo entregamos, sí. Funcional, testeado, documentado… pero sin propósito en el nuevo contexto del cliente.
Y ahí entendí algo que ningún curso de gestión de riesgos me había enseñado:
el mayor riesgo de un proyecto no siempre es técnico, ni operativo, ni de cronograma. A veces, es seguir construyendo algo que ya no importa.
Moraleja (ahora sí, la verdadera):
La matriz de riesgos es vital, pero no lo es todo. Aprende a leer las señales del negocio, no solo del backlog.
Los riesgos estratégicos no hacen ruido. Pero cuando explotan, no dejan escombros… dejan irrelevancia.
Anticiparse no es paranoia. Es una forma de respeto hacia el esfuerzo del equipo.
No te enamores del proyecto. Enamórate del problema que resuelve. Porque si el problema cambia… el proyecto también debería.
Este fue uno de esos proyectos que dejan cicatrices… pero también aprendizajes valiosos.
Y ahora te toca:
Yendry Sánchez, PMO Manager - Blog Centro de Control
+506 40014370
This is a mockup. Publish to view how it will appear live.