Comprenda Delay Analysis y Time Impact Analysis en ingeniería: baseline, camino crítico, TIA, análisis por ventanas, concurrency, float, evidencias y extensión de plazo.
¡Descúbrelo!
Delay Analysis es el análisis técnico utilizado para determinar cómo determinados eventos afectaron o pueden afectar el plazo de un proyecto, especialmente su fecha de finalización y los hitos contractuales. En ingeniería y construcción, el análisis debe ir más allá de constatar que “hubo un atraso”: debe identificar la baseline, el camino crítico aplicable, la secuencia afectada, el momento del evento, la responsabilidad contractual y el efecto temporal demostrable.
Time Impact Analysis (TIA) es uno de los posibles métodos de análisis de atrasos. Normalmente evalúa, de forma prospectiva o contemporánea, la inserción de un evento o fragnet en un cronograma actualizado para observar su influencia sobre el camino crítico y las fechas contractuales. TIA no es sinónimo de toda Delay Analysis, y su adecuación depende de la calidad del cronograma, del momento en que se realiza el análisis y de la pregunta que debe responderse.
En claims de plazo, la solidez está en la relación entre el cronograma y la realidad. Un método sofisticado aplicado sobre una baseline débil, una lógica incompleta o updates que no reflejan el campo puede producir una apariencia de precisión sin representar lo que realmente ocurrió.
Delay, disruption y prolongación son efectos diferentes
El Society of Construction Law Delay and Disruption Protocol distingue delay y disruption porque, aunque pueden originarse en el mismo evento, no representan el mismo efecto. Delay está asociado al tiempo y a la finalización; disruption está asociada a la pérdida de productividad o a cambios en la eficiencia del trabajo. Un evento puede producir ambos efectos, solo uno de ellos o efectos en períodos distintos.
| Efecto | Pregunta principal | Evidencia principal |
| delay | ¿se desplazó la finalización o un hito? | cronograma, lógica, camino crítico, updates |
| disruption | ¿el trabajo se volvió menos productivo? | producción, recursos, frentes, secuencia, horas |
| prolongación | ¿el proyecto permaneció movilizado durante más tiempo? | costos dependientes de duración y período efectivo |
| aceleración | ¿se modificaron recursos o secuencia para recuperar plazo? | instrucciones, plan de recuperación, recursos y desempeño |
Esta separación es importante porque un claim puede solicitar una extensión de plazo sin costos por improductividad, o demostrar pérdida de productividad sin desplazar la fecha final.
El punto de partida es una baseline confiable
La baseline debe representar el plan contractual o técnicamente aceptado contra el cual se analizará el evento. Esto exige fechas, lógica, duraciones, calendarios, hitos, restricciones y premisas coherentes.
El análisis no debe comenzar por la diferencia entre la fecha planificada y la fecha real. Antes, es necesario verificar si el cronograma de referencia era ejecutable, si contenía todas las actividades relevantes y si su lógica representaba la estrategia de implantación.
En contratos estructurados por Work Packages, la descomposición ayuda a conectar entregables, responsables e interfaces con las actividades del cronograma. Cuanto menos clara sea esta relación, más difícil será demostrar la causalidad temporal.
El camino crítico no es una línea fija durante todo el proyecto
El camino crítico puede migrar. Una actividad crítica en la baseline puede dejar de controlar la finalización después de cambios, avances, atrasos concurrentes o replanificación. Por eso, los análisis de atraso deben considerar el estado del proyecto en el momento del evento.
La simple afirmación “la actividad estaba en el camino crítico original” puede ser insuficiente meses después. El análisis debe verificar la red lógica contemporánea, el float disponible y las condiciones reales de ejecución.
Este punto explica por qué los updates periódicos de buena calidad son tan importantes. Registran la evolución del plan y reducen la necesidad de reconstruir retrospectivamente el camino crítico.
Prospectivo vs. retrospectivo
La elección del método depende, entre otros factores, del momento en que se realiza el análisis.
| Enfoque | Momento | Uso típico |
| prospectivo | antes de que se materialice todo el impacto | estimar el efecto probable y apoyar una decisión contemporánea |
| contemporáneo | durante la ocurrencia | evaluar extensión de plazo, mitigación y cambio |
| retrospectivo | después del período o de la finalización | reconstruir y explicar los efectos realmente ocurridos |
Un enfoque prospectivo no debe juzgarse como si tuviera acceso a hechos posteriores. Del mismo modo, un análisis retrospectivo no debe ignorar lo que efectivamente ocurrió en favor de una simulación que nunca se materializó.
Qué es Time Impact Analysis
TIA inserta una representación lógica del evento — a menudo llamada fragnet — en un cronograma de referencia actualizado y calcula su influencia sobre la red. El objetivo es observar cómo el evento modifica fechas, camino crítico, float o hitos.
La calidad de la TIA depende de la credibilidad del update seleccionado y de la modelización del evento. Si el fragnet exagera la duración, crea dependencias artificiales o ignora actividades paralelas, el resultado puede sobreestimar el impacto.
Cuándo TIA tiene más sentido
TIA tiende a ser más útil cuando el proyecto todavía está en curso, existe un cronograma actualizado confiable y el evento puede representarse mediante actividades y relaciones lógicas verificables.
Es especialmente valiosa cuando la decisión debe tomarse antes del cierre, por ejemplo para evaluar una extensión de plazo, change order, acceso tardío, atraso de información, cambio de proyecto o instrucción que altere la secuencia.
Pierde fuerza cuando no existen updates confiables, cuando el análisis se realiza mucho después del evento o cuando la lógica del cronograma no representa la ejecución real. En esos casos, otros métodos retrospectivos pueden ser más adecuados.
TIA no debe ser una simulación desconectada de la ejecución
Una TIA bien estructurada debe confrontar el modelo con hechos contemporáneos: fechas reales, frentes disponibles, restricciones, recursos, avance, decisiones y condiciones de acceso.
También debe considerar la mitigación. Si el equipo logró resecuenciar actividades, abrir otro frente o anticipar parte del trabajo, el efecto final puede ser menor que el impacto bruto inicialmente proyectado.
El análisis técnico debe documentar las premisas y limitar las conclusiones a lo que los datos permiten afirmar. En proyectos con baja calidad de planificación, la incertidumbre metodológica debe aparecer en el dictamen.
Cuando un atraso relevante debe sustentar una negociación, extensión de plazo o respuesta a un claim, la metodología debe definirse a partir de la calidad del cronograma y de las evidencias — no del resultado que una de las partes desea obtener.
Estructure un análisis técnico de plazo integrado al claim contractual
Análisis por ventanas
Window Analysis divide el proyecto en períodos y examina la evolución del camino crítico y de los atrasos en cada ventana. La lógica es útil en proyectos largos en los que la criticidad, la secuencia y los eventos cambian significativamente a lo largo del tiempo.
El tamaño de las ventanas puede seguir updates mensuales, hitos o períodos con características similares. Las ventanas cortas aumentan el detalle, pero exigen datos consistentes; las ventanas amplias pueden ocultar cambios relevantes.
El análisis debe explicar por qué se eligió determinada división y cómo se asignaron los eventos a cada período.
As-planned vs. as-built
Comparar la planificación original con la ejecución real es intuitivo y puede ofrecer una visión general, pero por sí solo no demuestra causalidad. La diferencia entre dos fechas no informa qué evento produjo el desvío ni si el atraso era crítico cuando ocurrió.
Este tipo de comparación puede apoyar un diagnóstico inicial, pero los claims complejos normalmente exigen analizar la lógica y la evolución temporal.
Collapsed as-built y enfoques retrospectivos
Los métodos retrospectivos pueden eliminar del as-built determinados eventos para estimar cuál habría sido la finalización “but for” esos impactos. Esta lógica se asocia frecuentemente al collapsed as-built.
El desafío es reconstruir una red lógica confiable a partir de la ejecución real. Si las relaciones entre actividades no están demostradas, la eliminación de eventos puede crear una condición hipotética alejada de lo que habría sido técnicamente posible.
Ningún método debe elegirse únicamente porque produzca un número favorable. El método debe responder la pregunta con los datos disponibles.
Cómo elegir el método de Delay Analysis
La selección debe considerar la calidad de la baseline, la calidad de los updates, la etapa del proyecto, la cantidad de eventos, la existencia de registros contemporáneos, la complejidad de la lógica y la finalidad del análisis.
El SCL Protocol recomienda que la elección de la metodología considere la naturaleza del proyecto, la documentación disponible y la proporcionalidad. En términos de ingeniería, esto significa que el método debe ser defendible antes de ser conveniente.
Un análisis puede incluso combinar técnicas, siempre que se expliciten los límites y no se mezclen premisas incompatibles.
Eventos de atraso y Claim Management
Delay Analysis funciona mejor cuando los eventos ya fueron controlados durante la ejecución. Claim Management crea la trazabilidad de notices, evidencias, decisiones y registros que posteriormente utilizará el análisis de plazo.
Cuando el proyecto llega al final sin un event register, las fechas de inicio y fin de los impactos deben reconstruirse a partir de actas, correos electrónicos, diarios y logs. Esto aumenta el costo y la incertidumbre.
Delay Analysis dentro de un claim contractual
El claim contractual necesita integrar la conclusión temporal con el fundamento contractual. Demostrar 20 días de impacto en una red no significa automáticamente tener derecho a 20 días de extensión.
Es necesario confrontar el evento con las cláusulas, la matriz de riesgos, los notices, la responsabilidad, la concurrencia de atrasos, la mitigación y las condiciones específicas del contrato.
El análisis del cronograma informa el efecto técnico. El entitlement determina cómo se tratará ese efecto contractualmente.
Concurrency: los atrasos simultáneos exigen un análisis cuidadoso
Concurrency no debe tratarse únicamente como la presencia de dos problemas en el mismo mes. La cuestión es verificar si eventos bajo responsabilidades distintas afectaron simultáneamente el camino crítico o la finalización relevante.
La definición y el efecto jurídico de concurrency varían según el contrato y la legislación aplicable. El análisis de ingeniería debe limitarse a demostrar cronología, criticidad y superposición técnica, dejando la consecuencia jurídica a la interpretación competente.
Los cronogramas poco actualizados dificultan esta evaluación porque ocultan la migración de criticidad entre frentes.
Float y responsabilidad por el tiempo disponible
Float representa flexibilidad de la red, pero su tratamiento contractual puede ser controvertido. Un evento puede consumir float sin modificar la fecha final; otro puede transformar una actividad antes no crítica en crítica.
El análisis debe mostrar el float disponible en el momento del evento y cómo evolucionó. No es adecuado presumir que todo consumo de float equivale a una extensión de plazo.
También es importante verificar restricciones artificiales, lags excesivos y calendarios que puedan distorsionar el cálculo.
Data date, actualización y estado real
Cada update necesita una fecha de estado clara y debe separar trabajo finalizado, en curso y futuro. Un avance incorrecto altera la red y puede crear criticidad artificial.
Antes de utilizar un update en Delay Analysis, conviene verificar fechas reales, porcentajes, remaining duration, relaciones abiertas, actividades fuera de secuencia, constraints e hitos.
Una auditoría del cronograma no es burocracia: es una precondición para confiar en el modelo.
Cuanto antes se gobiernen conjuntamente cronograma, alcance, interfaces y eventos contractuales, menor será la necesidad de reconstrucción forense al cierre y mayor la capacidad de decidir mientras todavía existe margen para mitigación.
Integre plazo, alcance y evidencias en la Gestión de Contratos, Alcance y Entregables
Auditar el cronograma antes de cualquier conclusión
Antes de aplicar TIA, Window Analysis o cualquier método retrospectivo, el cronograma debe auditarse como un modelo técnico. El análisis de atraso presupone que las relaciones, fechas y avance representan razonablemente la ejecución; si esta premisa falla, el resultado matemático puede amplificar errores de origen.
La auditoría debe examinar lógica abierta, actividades sin predecesora o sucesora cuando no sea justificable, constraints rígidas, lags elevados, calendarios incoherentes, duraciones remanentes incompatibles con el avance, actividades fuera de secuencia y cambios de lógica entre updates. También es necesario verificar si los hitos contractuales fueron modelados correctamente y si la fecha de estado se aplicó de manera consistente.
| Control | Riesgo para Delay Analysis | Verificación |
| lógica incompleta | crea un camino crítico artificial | predecesoras, sucesoras y relaciones |
| constraints rígidas | impiden que la red reaccione al evento | tipo, fecha y justificación de la restricción |
| avance inconsistente | distorsiona remaining duration y criticidad | fechas reales, porcentajes y registros de campo |
| cambio de lógica | puede reescribir retrospectivamente el plan | comparación entre updates sucesivos |
| calendarios | modifican duración y float sin un cambio aparente | jornadas, feriados, turnos y excepciones |
Una inconsistencia no vuelve automáticamente inutilizable el cronograma. El analista debe evaluar la materialidad, documentar ajustes cuando sean necesarios y explicar cómo cada limitación afecta el grado de confianza de la conclusión. En algunos casos, determinados períodos pueden analizarse con mayor confiabilidad que otros.
Cómo construir un fragnet técnicamente defendible
En TIA, el fragnet representa la lógica adicional creada por el evento. Su construcción exige más que insertar una actividad con duración igual al período reclamado. Es necesario modelar el mecanismo real de impacto: qué actividades fueron bloqueadas, qué nuevas etapas surgieron, qué aprobaciones pasaron a ser necesarias y dónde se conecta el evento con la red existente.
La duración del fragnet debe estar sustentada por registros contemporáneos o por una estimación técnica demostrable. Si una revisión de proyecto consumió diez días, por ejemplo, es necesario distinguir tiempo de elaboración, análisis, aprobación, movilización y efecto efectivo sobre el frente crítico. Sumar todos estos períodos sin verificar superposición puede sobreestimar el impacto.
Las relaciones lógicas también deben justificarse. Conectar el evento directamente a un hito final puede producir un efecto matemático sin representar el proceso ejecutivo. El fragnet debe entrar en la red donde realmente ocurrió la consecuencia, preservando actividades paralelas y alternativas disponibles.
Después de la inserción, la comparación debe mostrar no solo la diferencia de la fecha final, sino también el cambio del camino crítico, el consumo de float, las actividades que pasaron a controlar el hito y eventuales efectos absorbidos por la lógica existente.
Atraso excusable, compensable y no excusable: separar efecto de consecuencia
La clasificación contractual de un atraso no debe confundirse con su medición técnica. Delay Analysis puede demostrar que determinado evento desplazó un hito; aun así, el contrato puede atribuir consecuencias diferentes según la responsabilidad, la matriz de riesgos y las cláusulas aplicables.
En la terminología ampliamente utilizada en contratos de construcción, un atraso excusable puede justificar una extensión de plazo, mientras que un atraso compensable puede, además del tiempo, sustentar determinados costos adicionales. Un atraso no excusable permanece bajo responsabilidad de la parte que asumió el riesgo o produjo el evento. La definición concreta depende del contrato y de la legislación aplicable; por lo tanto, el análisis de ingeniería debe evitar transformar estas categorías en una conclusión jurídica automática.
Esta separación mejora el dictamen. Primero se demuestra el efecto temporal: evento, período, actividad, criticidad e impacto neto. Después se aplica la lectura contractual para determinar si ese efecto es reconocible como extensión, compensación, riesgo asumido u otro tratamiento.
En proyectos con varios eventos, la clasificación también ayuda a evitar compensaciones cruzadas mal justificadas. Dos atrasos pueden ocurrir en el mismo período y tener consecuencias contractuales distintas, aunque ambos aparezcan en la evolución de la red.
La extensión de plazo y los costos de prolongación no son la misma demostración
Demostrar el derecho técnico a una extensión de plazo no determina automáticamente el valor de los costos de prolongación. El primer análisis responde cuántos días determinados eventos afectaron la finalización o hitos relevantes. El segundo debe demostrar qué costos adicionales resultaron del aumento efectivo de la duración.
Los costos de prolongación pueden involucrar equipo de gestión, instalaciones temporales, seguridad, equipos, alquileres, seguros, administración de campo y otros ítems dependientes del tiempo. Sin embargo, cada componente debe confrontarse con el período real, la estructura movilizada y los mecanismos ya remunerados por el contrato.
Tampoco es adecuado multiplicar automáticamente un costo diario promedio por el número de días de Delay Analysis. La estructura de costos puede variar durante el proyecto, parte de los recursos puede haber sido desmovilizada y determinados costos pueden existir independientemente del atraso.
Por eso, los claims robustos tratan plazo y quantum como análisis conectados, pero distintos. El cronograma establece la ventana temporal causal; los registros de costos demuestran lo que efectivamente ocurrió dentro de ella. La convergencia de ambas líneas produce una conclusión más defendible que una simple extrapolación financiera a partir de los días calculados.
Evidencias que sustentan un análisis de atraso
El cronograma por sí solo rara vez es suficiente. El análisis debe cruzar la red con documentos de ejecución.
Actas, RFIs, diarios, informes, registros fotográficos, entregables de proyecto, liberaciones de acceso, movilización, procurement, logs de equipos, pruebas y correspondencias ayudan a definir inicio, fin y mecanismo de cada evento.
Esta triangulación reduce el riesgo de modelar fechas únicamente a partir de la narrativa posterior de las partes.
Atraso de proveedor e interfaces entre contratos
En proyectos con múltiples paquetes, un proveedor puede atrasar a otro sin que exista una relación contractual directa entre ellos. El análisis debe rastrear la interfaz: qué entrega era predecesora, cuándo era necesaria, cuándo fue disponibilizada y qué alternativa existía.
La Gestión de Contratos, Alcance y Entregables ayuda a formalizar estas fronteras antes de que la responsabilidad se vuelva difusa.
Mitigación, resecuenciación y plan de recuperación
Cuando un evento amenaza un hito, el equipo puede resecuenciar, aumentar recursos, cambiar turnos, liberar frentes parciales o modificar el método ejecutivo. Estas acciones deben reflejarse en el análisis.
Una mitigación razonable no significa eliminar todo impacto a cualquier costo. El dictamen debe distinguir medidas ordinarias de acciones extraordinarias de aceleración y registrar sus efectos.
Un plan de recuperación tampoco borra automáticamente un atraso ya ocurrido; muestra cómo la organización pretende controlar el resto de la ejecución.
Cómo presentar la conclusión de una Delay Analysis
Una conclusión útil no debe limitarse a indicar “X días de atraso”. Debe explicar evento, período, cronograma de referencia, método, camino crítico, premisas, resultado, concurrencias, mitigación y limitaciones.
Una tabla por evento suele ser más útil que una narrativa única:
| Evento | Período | Actividad afectada | Criticidad | Impacto neto | Evidencia | Observación |
| cambio A | fechas verificadas | paquete/sistema | crítica o no | días | documentos | premisas |
La transparencia metodológica permite que otro equipo reproduzca el razonamiento y cuestione premisas específicas sin rechazar todo el análisis.
Errores frecuentes en los análisis de atraso
Un error es partir de la fecha final y distribuir la responsabilidad retrospectivamente. Otro es utilizar la baseline original para todos los eventos sin observar la evolución del camino crítico. También son problemáticos los fragnets sin base factual, los updates no auditados, la ausencia de fecha de estado y la mezcla entre atraso e improductividad.
Otro error común es presentar un resultado matemático como conclusión contractual. Delay Analysis demuestra impacto temporal; entitlement, riesgos y cláusulas determinan la consecuencia de ese impacto.
Consideraciones finales
Delay Analysis es una disciplina de causalidad temporal. Su objetivo es explicar, mediante cronograma y evidencias, cómo los eventos modificaron la secuencia y los hitos del proyecto. Time Impact Analysis es una herramienta importante dentro de este campo, especialmente para análisis contemporáneos o prospectivos, pero no es adecuada para todos los casos.
La calidad de la conclusión depende menos del software utilizado y más de la calidad de la baseline, de los updates, de la modelización del evento y de los registros contemporáneos. Método y datos deben ser compatibles.
Cuando el análisis se integra con Claim Management y la gobernanza contractual, el cronograma deja de ser solamente una herramienta de seguimiento y pasa a sustentar decisiones sobre cambios, extensión de plazo, mitigación y negociación.
Referencias técnicas
[1] SOCIETY OF CONSTRUCTION LAW. Delay and Disruption Protocol. 2. ed. London: SCL, 2017. Disponible en: https://www.scl.org.uk/sites/default/files/documents/SCL_Delay_Protocol_2nd_Edition_Final.pdf
[2] AACE INTERNATIONAL. Recommended Practices. Biblioteca de referencias técnicas, incluidas prácticas de análisis forense de cronogramas. Disponible en: https://web.aacei.org/resources/recommended-practices
[3] AACE INTERNATIONAL. A Primer for Claims and Disputes (Claims 101). Source Extra, 24 ago. 2022. Disponible en: https://source.aacei.org/2022/08/24/a-primer-for-claims-and-disputes-claims-101/
Preguntas frecuentes
Es el análisis técnico que utiliza cronogramas y evidencias para determinar cómo determinados eventos afectaron o pueden afectar el camino crítico, los hitos y la fecha de finalización de un proyecto.
Es un método que modela un evento o fragnet en un cronograma actualizado para evaluar su efecto probable sobre la red, el camino crítico y los hitos.
No. Existen enfoques prospectivos y retrospectivos, incluidos análisis por ventanas, comparaciones as-planned vs. as-built y métodos basados en el as-built. La elección depende de los datos y de la finalidad.
Delay está asociado al tiempo y a la finalización; disruption está asociada a la pérdida de productividad y eficiencia. Un mismo evento puede producir ambos efectos.
No. El análisis debe considerar updates, el camino crítico contemporáneo, eventos, evidencias de campo, mitigación y condiciones contractuales.
No. El análisis demuestra el efecto temporal. El entitlement depende del contrato, la matriz de riesgos, notices, responsabilidad y reglas aplicables.
Materiales técnicos complementarios
Contenidos principales sobre el tema
- Claim Management en Proyectos de Ingeniería
- Claim Contractual en Ingeniería: cómo estructurar técnicamente un Claim
- Reequilibrio Económico-Financiero en Contratos de Ingeniería
Contenidos técnicos relacionados
- Work Package en Proyectos de Ingeniería
- Riesgos Contractuales y de Proveedores en Proyectos de Ingeniería
