EVM para Proyectos de TI y Software
Aplicar la Gestión del Valor Ganado (GVG/EVM) a proyectos de TI y software es más complejo que en la construcción. El trabajo de software es abstracto, los requisitos pueden cambiar a mitad del proyecto, y medir el "porcentaje completado" de una función es inherentemente subjetivo. Sin embargo, con las adaptaciones correctas, el EVM aporta un valor enorme.
El desafío central: medir el Valor Ganado en software
1. Story Points (EVM Ágil)
En entornos Scrum o Kanban, los equipos estiman el trabajo en story points. El EVM se puede construir sobre esto:
- BAC = Total story points × costo promedio por story point
- VP = Story points planificados hasta el sprint actual
- VG = Story points realmente completados × costo por story point
- CR = Costos reales del equipo (salarios, infraestructura, licencias) para el período
2. EVM basado en hitos (cascada)
Para proyectos en cascada, asigne pesos presupuestarios a los hitos. El Valor Ganado solo se acredita cuando cada hito está totalmente completado y aceptado.
Ejemplo práctico
Desarrollo de un CRM: BAC = $400.000, 8 sprints. Tras el sprint 4:
IDC = 160.000 ÷ 195.000 = 0,821 (18% de sobrecosto)
IDCr = 160.000 ÷ 200.000 = 0,800 (20% de retraso)
EAC = 400.000 ÷ 0,821 = $487.211
IDCr = 160.000 ÷ 200.000 = 0,800 (20% de retraso)
EAC = 400.000 ÷ 0,821 = $487.211
Objeciones comunes al EVM ágil
- «El Ágil no tiene alcance fijo»: el EVM funciona con un backlog priorizado — el BAC representa el alcance del release acordado
- «Los requisitos cambian cada sprint»: use un proceso de control de cambios
- «No estimamos de antemano»: el EVM requiere una línea base — las story points relativas pueden formarla
Consejos prácticos para directores de proyectos TI
- Establecer el BAC antes del sprint, no después
- Solo acreditar 0% o 100% para stories en progreso — sin crédito parcial
- Rastrear tendencias del IDC semanalmente — el reporte mensual suele llegar demasiado tarde