Dashboard de proyectos: la vista, no los 40 KPIs

Un dashboard de proyectos es una superficie donde mirar, en una pantalla y en menos de un minuto, el estado real de lo que tienes en marcha. Eso es todo. No es un sistema que genera datos: los toma de donde ya viven —el tablero, las fechas, los bloqueos— y los pone a la vista. La distinción importa porque el 90 % de los dashboards fallidos mueren por lo contrario: se construyen como un proyecto paralelo que exige alimentar datos que nadie anota.

Tampoco es lo mismo que un KPI. El KPI es el indicador: una métrica con objetivo y umbral, tipo lead time menor de cinco días. El dashboard es la ventana donde miras ese y otros indicadores juntos. Primero defines qué medir —la selección de indicadores con sus umbrales está en KPIs de gestión de proyectos— y después decides dónde mirarlos. Si haces el dashboard antes que los KPI, te quedas con gráficos bonitos sin dueño ni objetivo.

La prueba de fuego es simple: si el tablero responde «¿cómo vamos?» sin que nadie tenga que preparar nada, es un dashboard. Si responder requiere una reunión previa o exportar planillas, es un reporte disfrazado.

No necesitas más que esto. Cinco vistas que responden las cinco preguntas que un responsable de proyectos se hace cada mañana:

Con estas cinco vistas cubres avance, futuro, riesgo, capacidad y control de cambios. Cualquier gráfico adicional tiene que ganarse su lugar respondiendo una pregunta que alguien haga de verdad cada semana. Si nadie la hace, sobra.

El exceso es la razón número uno por la que los tableros de control mueren en tres meses. Estos son los sospechosos habituales:

• Cuarenta gráficos para todo. Si el dashboard tiene más widgets que proyectos, nadie lo mira. La regla es una pantalla, un minuto, una respuesta.
• Métricas sin dueño. Un indicador que nadie tiene obligación de mover ni de explicar no es información: es decoración. Cada vista necesita un nombre al lado.
• Vanity metrics. Tareas creadas, horas registradas, mensajes enviados: crecen siempre y no predicen entrega. Solo importan las métricas que cambian cuando el proyecto se desvía.
• Semáforos sin criterio. Verde, amarillo y rojo acordados por corazonada significan que todos los proyectos estarán en amarillo para no incomodar. El color necesita definición escrita: rojo es fecha en riesgo o bloqueo de más de una semana, no «algo de tensión».

Y el síntoma definitivo: si el dashboard solo se abre cuando alguien de arriba pide números, no es un tablero de control, es un trámite. El buen dashboard se mira solo, porque está en la pantalla del equipo, no en un archivo que se envía.

Armado como vista de datos existentes, un dashboard útil sale en una tarde. El orden:

1. Define la fuente única. Un solo lugar donde vive el trabajo: el tablero del equipo. Si el trabajo está en el tablero y el «estado» está en una planilla aparte, ya perdiste: dos fuentes nunca coinciden.
2. Actualiza en el momento, no por reporte. La regla cultural que sostiene todo: quien mueve una tarjeta, actualiza su estado ahí mismo. Sin esta regla, cualquier dashboard miente en cuestión de días.
3. Empieza con las cinco vistas. Avance, entregas, riesgos, carga y desvíos. Nada más el primer mes; lo que falte aparecerá solo, pedido por alguien que lo necesita de verdad.
4. Si un dato hay que pedirlo, no va. Cada campo que exige preguntarle a alguien es un campo que estará vacío. Un dashboard se alimenta de lo que la gestión ya produce: estados, fechas, bloqueos y dueños.
5. Automatiza el resto. Lo que se puede calcular —conteos, porcentajes, fechas límite— se calcula solo. Ningún número del tablero debería escribirse dos veces.

El cambio real no es técnico sino de hábito: el dashboard deja de ser un entregable semanal y pasa a ser el subproducto del trabajo bien anotado. Cuando el tablero se actualiza en el momento, el dashboard ya está listo siempre; para ese modelo pull donde el tablero reemplaza a los reportes, mira ScrumBan.

Son dos alturas distintas y conviene no mezclarlas. El dashboard de un proyecto responde «¿cómo va este trabajo?»: su avance, sus bloqueos, su próxima entrega. El dashboard de portafolio sube un nivel y responde «¿cómo van todos y dónde pongo a la gente?»: estado de cada proyecto, demanda contra capacidad y qué decisiones tomar. Si intentas que un solo tablero haga las dos cosas, termina gigante y neutro: demasiado detalle para decidir, demasiado resumen para ejecutar.

La regla práctica: el equipo mira su dashboard de proyecto a diario; la dirección mira el de portafolio una vez al mes, en la revisión donde se prioriza y se pausa. La capa de decisión —qué entra, qué se detiene, quién se mueve— está desarrollada en portafolio de proyectos.

Si quieres este tipo de tablero sin pagar licencias por asiento —con dashboard de portafolio, kanban con límites WIP y datos que viven en tu carpeta en JSON local, sin cuenta— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — el dashboard se arma solo sobre tu tablero, local-first, sin nube.