Cómo automatizar el control RAID y EVM de un programa multipaís

El problema no es la plantilla, es el ciclo de reporte

Casi todos los programas multipaís que he visto tienen un RAID log y un cálculo de valor ganado. El problema nunca fue la ausencia de la herramienta: es que se llenan una vez al mes, a mano, a partir de conversaciones informales, y se leen recién cuando el problema ya explotó. Un RAID log que se actualiza mensualmente no es un instrumento de control, es un archivo histórico. Para que sirva, tiene que reflejar el estado real del programa con el mismo ciclo con el que se toman las decisiones: semanal, no mensual.

La automatización que describo acá no es sofisticada. No hay machine learning ni dashboards mágicos. Es disciplina de datos aplicada a algo tan aburrido como un log de riesgos, y funciona precisamente porque es aburrida y consistente.

Qué es EVM en la práctica, sin la jerga

El valor ganado (Earned Value Management) responde una pregunta simple que la mayoría de los reportes de estado no responden: de lo que deberíamos haber avanzado a esta fecha, cuánto avanzamos realmente, y a qué costo. Dos números hacen casi todo el trabajo:

Un programa puede reportarse "en verde" en las minutas y tener un CPI de 0.85 hace tres semanas. Esa brecha entre percepción y número es exactamente lo que el EVM está diseñado para exponer, si se calcula seguido y no una vez al cierre de fase.

Qué es un RAID log y por qué la mayoría lo llenan mal

RAID es Risks, Assumptions, Issues, Dependencies: riesgos, supuestos, problemas ya materializados y dependencias entre equipos o proveedores. El error común no es la estructura, es el tratamiento: un RAID log que solo se abre en el comité mensual se convierte en una lista de cosas que ya pasaron, no en una herramienta para anticipar lo que va a pasar. Las tres reglas que hacen la diferencia:

• Todo ítem tiene un dueño, no un área. "Equipo de datos" no es un responsable; una persona con nombre lo es.
• Todo ítem tiene fecha de revisión, no solo de cierre. Un riesgo sin fecha de próxima revisión es un riesgo abandonado.
• Un ítem escalado deja de ser invisible. Si algo pasa de riesgo a problema, tiene que aparecer en la misma vista que ve el sponsor, no en una hoja aparte que nadie revisa.

El sistema: una sola fuente de verdad

Lo que construí no reemplaza el juicio de un PMO, automatiza la parte mecánica para que ese juicio tenga datos actualizados con qué trabajar. La idea central es simple: RAID log, cálculo de EVM, minutas de seguimiento y estado de facturación viven en un mismo lugar, con el mismo cronograma como fuente, en vez de cuatro archivos separados que alguien concilia a mano antes de cada comité.

En la práctica, esto significa:

1. El cronograma es la fuente única del cálculo de EVM. El avance planificado y el costo presupuestado salen del mismo cronograma que usa el equipo, no de una copia paralela en una planilla que se desincroniza en la segunda semana.
2. El RAID log alimenta las minutas, no al revés. Cada reunión de seguimiento parte de los ítems abiertos y su fecha de revisión, no de una discusión libre que después alguien intenta convertir en acta.
3. Un ítem de riesgo con impacto en costo se vincula a la línea de facturación correspondiente. Así el sponsor ve la relación directa entre "este riesgo se materializó" y "esto es lo que cuesta", sin esperar al cierre de mes para conectar los puntos.
4. El reporte semanal es una vista, no un documento nuevo que alguien redacta. Si los datos están actualizados, el reporte se genera; no se escribe desde cero cada semana.

Por dónde empezar si tu programa todavía reporta a mano

No recomiendo construir las cuatro piezas a la vez. El orden que me ha funcionado: primero un RAID log con dueño y fecha de revisión por ítem, actualizado semanalmente aunque sea en una planilla simple. Recién cuando ese hábito esté instalado, y solo entonces, tiene sentido conectar el cálculo de EVM al mismo cronograma. Automatizar un mal hábito de reporte solo lo hace más rápido de repetir.