Delay event register: la bitácora que salva tus reclamos por atraso

Casi todos los reclamos por atraso mueren por la misma razón: cuando llega el momento de sostenerlos, la evidencia ya no existe. El atraso pasó hace ocho meses, la persona que estuvo ahí ya no está en el proyecto, los correos están dispersos en tres bandejas de entrada, y nadie anotó qué día exactamente el cliente entregó tarde la información que frenó la ingeniería. El delay event register —o registro de eventos de atraso— existe precisamente para que eso no pase.

Es, en esencia, una bitácora viva: una lista donde cada vez que algo atrasa (o amenaza con atrasar) el proyecto, se anota el evento en el momento en que ocurre, con su causa, su fecha y su impacto estimado. No es un documento que se arma al final para reclamar — es un hábito que se mantiene durante toda la ejecución.

Qué debería contener cada entrada

Un buen registro no necesita ser complejo, pero sí consistente. Cada evento de atraso debería capturar al menos:

• Fecha del evento: cuándo ocurrió, no cuándo lo anotaste. Si hay diferencia, registra ambas.
• Descripción del evento: qué pasó, en lenguaje concreto y verificable — "el cliente entregó la revisión de la memoria de cálculo el 14, no el 1 como estaba comprometido", no "hubo demoras del cliente".
• Causa y parte responsable: cliente, contratista, proveedor o fuerza mayor. Esta es la clasificación que después determina si el atraso es disculpable y/o compensable.
• Actividades afectadas: qué tareas del cronograma se ven impactadas, y críticamente, si alguna está en la ruta crítica.
• Impacto estimado en días: tu mejor estimación del atraso que genera, sabiendo que se refinará después. Un número imperfecto anotado a tiempo vale más que uno perfecto calculado tarde.
• Evidencia de respaldo: el correo, la minuta, la notificación formal, el número de RFI o transmittal que documenta el evento. El registro apunta a la evidencia; no la reemplaza.
• Estado y notificación: si el evento fue notificado formalmente a la contraparte y cuándo — muchos contratos exigen notificación dentro de un plazo, y perderlo puede invalidar el derecho a reclamar aunque el atraso sea real.

Por qué la mayoría no lo hace (y por qué debería)

El registro de eventos de atraso es una de esas prácticas que todos reconocen como buena idea y casi nadie mantiene. La razón es simple: durante la ejecución, cuando el evento ocurre, el equipo está ocupado apagando el incendio, no documentándolo. Anotar el atraso se siente como burocracia que no ayuda a resolver el problema de hoy. El costo de no hacerlo aparece meses después, cuando ya es demasiado tarde para arreglarlo.

Hay además una resistencia más incómoda: registrar un atraso propio por escrito se siente como dejar evidencia en contra. Pero un registro honesto que incluye los atrasos del contratista es precisamente lo que le da credibilidad cuando señala los del cliente. Un registro que solo apunta a la contraparte se lee como lo que es — un documento parcial armado para reclamar.

Del registro a la acción

Un buen registro no solo sirve para reclamar al final — usado bien, es una herramienta de gestión en tiempo real. Si al cierre de cada mes revisas los eventos acumulados, puedes ver patrones antes de que se vuelvan crónicos: si el 70% de tus atrasos vienen de información tardía del cliente, esa es una conversación que conviene tener en el mes tres, no en el reclamo final. El registro convierte quejas dispersas en un caso con números.

Y cuando llega el momento de un análisis forense por ventanas, el registro es el esqueleto sobre el que se construye: cada ventana de análisis se nutre de los eventos que ya documentaste en ese período, con las fechas y causas que anotaste cuando todavía estaban frescas.

La regla práctica

No necesitas un software caro ni un procedimiento de cincuenta páginas para empezar. Una planilla compartida, disciplina para llenarla el mismo día que ocurre el evento, y la costumbre de adjuntar siempre la evidencia de respaldo, ya te ponen por delante de la mayoría de los proyectos. La regla es una sola: anota el evento cuando ocurre, no cuando lo necesitas. Para cuando lo necesitas, ya es tarde.