Empieza un programa de transformación digital. Hacemos la reunión de kick-off con todos los involucrados. Una presentación de 40 diapositivas. Presentamos la matriz de riesgos. Cortamos la cinta. Aplaudimos.
Ahora bien, como persona interesada, más allá de esa primera reunión, ¿alguna vez volviste a mirar la matriz de riesgos durante el proyecto? ¿O asumiste que, si algo cambiaba y te afectaba, alguien te lo iba a avisar?
Como Program Manager, ¿cuántas veces has analizado exhaustivamente todos los riesgos, generado una matriz impecable… solo para abandonarla pocas semanas después de iniciar el programa?
El límite de un plan
La gestión de riesgos y dependencias es, probablemente, la parte más difícil del trabajo de un Program Manager. Y, en mi opinión, gran parte de la dificultad surge de intentar manejar riesgos en cascada: planificamos, ejecutamos, monitoreamos. Creemos haber hecho un buen trabajo al principio, identificamos y documentamos todos, y luego solo queda aplicar los planes y seguir indicadores. Al menos, así parecen verlo la mayoría de los stakeholders con los que he trabajado.
Ese enfoque puede funcionar en un entorno simple, con un proyecto pequeño y un solo equipo (recordemos que un equipo Scrum son entre 5 y 7 personas).
Si este es tu caso, una matriz con probabilidad e impacto (alto, medio, bajo), planes de acción (transferir, mitigar, evitar etc) y colores de semáforo (verde, amarillo, rojo) puede ser suficiente. Los riesgos más comunes están bien cubiertos aquí:
Cuando ya no hablamos de proyectos
Para los que quieren aprender a resolver un desafío más grande, quiero compartir una convicción basada en mi experiencia – si tienes más de 10 personas en tu lista de stakeholders, lo que gestionas es un programa, aunque lo llamen proyecto.
Y con esto, aparecen riesgos que no verás en un proyecto individual.
La mala noticia: los riesgos de los proyectos siguen ahí. Los riesgos de programas se suman a los de los proyectos, agregando complejidad y dinamismo.
Un “proyecto” con 35 participantes y tres células de trabajo no puede tratarse como tal: requiere gestión centralizada de programa. Programas de esta envergadura intentan de disfrazarse de proyectos para ahorrar costos, pero al hacer esto caen en la no identificación ni gestión adecuada de riesgos de programas.
Riesgos típicos de programas
- Dependencias. No puedo enfatizar lo suficiente la importancia de dependencias. En un equipo Scrum pequeño, un cambio en el backlog puede acomodarse. Pero que pasa, si en el mismo “proyecto” hay más de una celula? Un cambio en el backlog de frontend desencadena un cambio en el backlog de arquitectura, un cambio en el backlog de backend, un cambio en la secuencia de integraciones y pruebas. O, digamos, en un programa de fidelización de clientes, el equipo de data olvida un componente necesario para procesar el tipo de data que necesita marketing y se demora un mes en conseguir presupuesto y negociar con proveedores. Para cuando todo está listo… ¡la Navidad ya había pasado!
- Riesgos en tensión. Son muy interesantes las conversaciones sobre si un modulo del sistema debería ser customizado o comprado out-of-the-box. Este es un ejemplo claro de los trade-offs en la gestión de riesgos de un programa. Si compramos este componente hecho, ahorramos en desarrollo, soporte, actualizaciones. Mitigamos riesgos financieros, de performance, de calidad de código. Pero como no es exactamente lo que necesitamos, aumentan otros riesgos: clientes insatisfechos, ventas perdidas, retrabajos manuales en Excel, la lista sigue.
- Entorno VUCA (Volatilidad, Incertidumbre, Complejidad y Ambigüedad). Para un proyecto simple el entorno se puede obviar. El plazo y el alcance de estos permiten entregarlos suficientemente rápido. Pero en programas de meses o años, con equipos grandes y sponsors múltiples, todo puede cambiar: un sponsor clave acepta otro trabajo, la empresa ajusta presupuestos, o se decide cambiar la tecnología y el equipo no domina la nueva herramienta. El plan más completo se vuelve obsoleto sin un mecanismo de adaptación continua.
Llegamos a la parte final por hoy. ¿Cómo lo resolvemos?
(Image credit: Warner Bros.)
Orquestar en lugar de controlar
En mis artículos anteriores, hablo de orquestación. El uso de esta palabra no es casual. Así como una orquesta necesita armonizar distintos instrumentos, un programa requiere coordinar los riesgos de cada frente para que no se conviertan en ruido caótico.
Orquestar riesgos implica:
- Gestionar interdependencias: entender cómo un riesgo local afecta al resto del programa. Si aplico esta solución, es gratis para el resto del programa? La puedo deshacer? Cuanto me va a costar deshacerla en todo el programa?
- Visualizar la red de riesgos: no solo listarlos, sino ver conexiones. ¿Puedo descomponer el riesgo grande en varios pequeños y trabajar con cada uno por separado? ¿Un plan positivo en un frente puede generar un efecto contrario en otro? Presten especial atención a agilidad vs seguridad.
- Construir escenarios dinámicos: simular qué pasa si ocurren dos o más riesgos a la vez. Generalmente solo hay presupuesto para un plan de mitigación, y el resto hay que resolverlo con workarounds o aceptación. Busca planes de gestión complementarios – este lo resuelvo hoy, a este le aplico un workaround, y este otro lo puedo aceptar. Como decía Scarlett O’Hara: “pensaré en eso mañana”.
- Conectar niveles estratégicos y operativos: traducir riesgos técnicos en impacto de negocio. Muéstrale este articulo a tus stakeholders. Aplaudir cada dos semanas en las reuniones de avance, sin entender cómo evolucionan los riesgos, es fatal. Toma tu tiempo en medir el impacto de los riesgos en dólares y pesos. En mi experiencia, la monetización es la única forma de comparar con una base común y evitar sesgos de juicio. Y definitivamente te pondrá en el centro de atención.
Los stakeholders quizá no entienden Apigee, pero entienden $30,000 en pérdidas. Madurez en riesgos no es llenar dashboards: es anticipar y responder en equipo.
¿Ya has vivido un “efecto dominó” en tus programas? ¿Aprendiste algo? Comenta.
Soy Ludmila Solon, Senior Program Manager con 12+ años de experiencia trabajando en entornos multiculturales. Voy a seguir escribiendo semanalmente sobre la gestión de proyectos y programas. Si este contenido es de tu interés, te invito a suscribirte.