He visto dashboards de proyecto con 40 indicadores que nadie miraba y reports semanales de dos páginas que el sponsor abría sin leer. El problema no es la falta de datos: es el exceso de métricas que no guían ninguna decisión. Esta guía enumera solo las métricas que, en mi experiencia directa, realmente cambian el comportamiento de quien las lee.
1. Schedule Performance Index (SPI) y Cost Performance Index (CPI). Derivados del Earned Value Management, SPI y CPI siguen siendo los indicadores más fiables para proyectos con budget y schedule definidos. SPI por debajo de 1.0 indica retraso, CPI por debajo de 1.0 indica desviación de presupuesto. El valor real no es el número aislado, sino la tendencia: un SPI que baja semana tras semana es una señal de alarma mucho más útil que un dato negativo aislado.
2. Burn rate y runway (para proyectos con budget fijo). Cuánto presupuesto estás consumiendo por semana frente a cuánto queda. Para proyectos de timeline larga, este indicador anticipa un problema de presupuesto con semanas de antelación respecto a un report de costes consuntivos tradicional.
3. Lead time y cycle time (para equipos Kanban/flujo continuo). Para equipos que trabajan a flujo (soporte, operations, mantenimiento), velocity y burndown no tienen sentido. Lead time (del ingreso del task a la salida) y cycle time (del inicio de la elaboración efectiva a la salida) son las métricas correctas porque reflejan la experiencia real del stakeholder que espera el resultado.
4. Porcentaje de milestones alcanzadas on-time vs replanned. No basta con ver si una milestone se ha alcanzado: cuenta cuántas veces ha sido replanificada antes de conseguirlo. Una milestone alcanzada tras tres replanificaciones señala un problema de estimación o de execution que el simple 'alcanzada sí/no' oculta completamente.
5. El report que el sponsor realmente lee. El formato que mejor funciona en mi experiencia es una única página estructurada así: estado general (verde/amarillo/rojo) arriba, tres bullets sobre qué ha cambiado desde la semana pasada, los riesgos que requieren una decisión en los próximos 7 días, y nada más. Cada detalle adicional debe estar disponible bajo demanda, no incluido por defecto — el objetivo del report es generar decisiones, no demostrar cuánto trabajo se ha hecho.
Preguntas Frecuentes. ¿Cuántos KPI debería tener un dashboard de proyecto? Entre 4 y 6 para el nivel sponsor/board. El equipo operativo puede monitorizar más al nivel de detalle, pero la síntesis hacia arriba debe seguir siendo esencial. ¿EVM (Earned Value Management) sigue siendo relevante en 2026 con metodologías ágiles? Sí, en forma adaptada: muchos equipos ágiles aplican EVM a nivel de release o programa aunque no a nivel de sprint individual.
Si tu reporting de proyecto actual genera datos pero no decisiones, reservamos una call: te ayudo a rediseñar un set de KPI esencial y un formato de report que el sponsor lea de verdad.
