{"id":73495,"date":"2026-08-31T15:07:51","date_gmt":"2026-08-31T18:07:51","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=73495"},"modified":"2026-08-31T15:07:51","modified_gmt":"2026-08-31T18:07:51","slug":"delay-analysis-time-impact-analysis-ingenieria-proyectos-contratos","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/delay-analysis-time-impact-analysis-ingenieria-proyectos-contratos\/","title":{"rendered":"Delay Analysis y Time Impact Analysis en Ingenier\u00eda: c\u00f3mo evaluar atrasos en proyectos y contratos"},"content":{"rendered":"\n

Delay Analysis es el an\u00e1lisis t\u00e9cnico utilizado para determinar c\u00f3mo determinados eventos afectaron o pueden afectar el plazo de un proyecto, especialmente su fecha de finalizaci\u00f3n y los hitos contractuales. En ingenier\u00eda y construcci\u00f3n, el an\u00e1lisis debe ir m\u00e1s all\u00e1 de constatar que \u201chubo un atraso\u201d: debe identificar la baseline, el camino cr\u00edtico aplicable, la secuencia afectada, el momento del evento, la responsabilidad contractual y el efecto temporal demostrable.<\/p>\n\n\n\n

Time Impact Analysis (TIA) es uno de los posibles m\u00e9todos de an\u00e1lisis de atrasos. Normalmente eval\u00faa, de forma prospectiva o contempor\u00e1nea, la inserci\u00f3n de un evento o fragnet en un cronograma actualizado para observar su influencia sobre el camino cr\u00edtico y las fechas contractuales. TIA no es sin\u00f3nimo de toda Delay Analysis, y su adecuaci\u00f3n depende de la calidad del cronograma, del momento en que se realiza el an\u00e1lisis y de la pregunta que debe responderse.<\/p>\n\n\n\n

En claims de plazo, la solidez est\u00e1 en la relaci\u00f3n entre el cronograma y la realidad. Un m\u00e9todo sofisticado aplicado sobre una baseline d\u00e9bil, una l\u00f3gica incompleta o updates que no reflejan el campo puede producir una apariencia de precisi\u00f3n sin representar lo que realmente ocurri\u00f3.<\/p>\n\n\n\n

Delay, disruption y prolongaci\u00f3n son efectos diferentes<\/h2>\n\n\n\n

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\u00e1 asociado al tiempo y a la finalizaci\u00f3n; disruption est\u00e1 asociada a la p\u00e9rdida de productividad o a cambios en la eficiencia del trabajo. Un evento puede producir ambos efectos, solo uno de ellos o efectos en per\u00edodos distintos.<\/p>\n\n\n\n

Efecto<\/td>Pregunta principal<\/td>Evidencia principal<\/td><\/tr>
delay<\/td>\u00bfse desplaz\u00f3 la finalizaci\u00f3n o un hito?<\/td>cronograma, l\u00f3gica, camino cr\u00edtico, updates<\/td><\/tr>
disruption<\/td>\u00bfel trabajo se volvi\u00f3 menos productivo?<\/td>producci\u00f3n, recursos, frentes, secuencia, horas<\/td><\/tr>
prolongaci\u00f3n<\/td>\u00bfel proyecto permaneci\u00f3 movilizado durante m\u00e1s tiempo?<\/td>costos dependientes de duraci\u00f3n y per\u00edodo efectivo<\/td><\/tr>
aceleraci\u00f3n<\/td>\u00bfse modificaron recursos o secuencia para recuperar plazo?<\/td>instrucciones, plan de recuperaci\u00f3n, recursos y desempe\u00f1o<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esta separaci\u00f3n es importante porque un claim puede solicitar una extensi\u00f3n de plazo sin costos por improductividad, o demostrar p\u00e9rdida de productividad sin desplazar la fecha final.<\/p>\n\n\n\n

El punto de partida es una baseline confiable<\/h2>\n\n\n\n

La baseline debe representar el plan contractual o t\u00e9cnicamente aceptado contra el cual se analizar\u00e1 el evento. Esto exige fechas, l\u00f3gica, duraciones, calendarios, hitos, restricciones y premisas coherentes.<\/p>\n\n\n\n

El an\u00e1lisis 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\u00eda todas las actividades relevantes y si su l\u00f3gica representaba la estrategia de implantaci\u00f3n.<\/p>\n\n\n\n

En contratos estructurados por Work Packages<\/a>, la descomposici\u00f3n ayuda a conectar entregables, responsables e interfaces con las actividades del cronograma. Cuanto menos clara sea esta relaci\u00f3n, m\u00e1s dif\u00edcil ser\u00e1 demostrar la causalidad temporal.<\/p>\n\n\n\n

El camino cr\u00edtico no es una l\u00ednea fija durante todo el proyecto<\/h2>\n\n\n\n

El camino cr\u00edtico puede migrar. Una actividad cr\u00edtica en la baseline puede dejar de controlar la finalizaci\u00f3n despu\u00e9s de cambios, avances, atrasos concurrentes o replanificaci\u00f3n. Por eso, los an\u00e1lisis de atraso deben considerar el estado del proyecto en el momento del evento.<\/p>\n\n\n\n

La simple afirmaci\u00f3n \u201cla actividad estaba en el camino cr\u00edtico original\u201d puede ser insuficiente meses despu\u00e9s. El an\u00e1lisis debe verificar la red l\u00f3gica contempor\u00e1nea, el float disponible y las condiciones reales de ejecuci\u00f3n.<\/p>\n\n\n\n

Este punto explica por qu\u00e9 los updates peri\u00f3dicos de buena calidad son tan importantes. Registran la evoluci\u00f3n del plan y reducen la necesidad de reconstruir retrospectivamente el camino cr\u00edtico.<\/p>\n\n\n\n

Prospectivo vs. retrospectivo<\/h2>\n\n\n\n

La elecci\u00f3n del m\u00e9todo depende, entre otros factores, del momento en que se realiza el an\u00e1lisis.<\/p>\n\n\n\n

Enfoque<\/td>Momento<\/td>Uso t\u00edpico<\/td><\/tr>
prospectivo<\/td>antes de que se materialice todo el impacto<\/td>estimar el efecto probable y apoyar una decisi\u00f3n contempor\u00e1nea<\/td><\/tr>
contempor\u00e1neo<\/td>durante la ocurrencia<\/td>evaluar extensi\u00f3n de plazo, mitigaci\u00f3n y cambio<\/td><\/tr>
retrospectivo<\/td>despu\u00e9s del per\u00edodo o de la finalizaci\u00f3n<\/td>reconstruir y explicar los efectos realmente ocurridos<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Un enfoque prospectivo no debe juzgarse como si tuviera acceso a hechos posteriores. Del mismo modo, un an\u00e1lisis retrospectivo no debe ignorar lo que efectivamente ocurri\u00f3 en favor de una simulaci\u00f3n que nunca se materializ\u00f3.<\/p>\n\n\n\n

Qu\u00e9 es Time Impact Analysis<\/h2>\n\n\n\n

TIA inserta una representaci\u00f3n l\u00f3gica del evento \u2014 a menudo llamada fragnet \u2014 en un cronograma de referencia actualizado y calcula su influencia sobre la red. El objetivo es observar c\u00f3mo el evento modifica fechas, camino cr\u00edtico, float o hitos.<\/p>\n\n\n\n

L\u00f3gica simplificada de una Time Impact Analysis aplicada a un evento de proyecto<\/title><\/path><\/marker><\/path><\/marker><\/circle><\/marker><\/circle><\/marker><\/path><\/marker><\/path><\/marker><\/g><\/path><\/path><\/path><\/path><\/path><\/path><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/rect>

Update anterior al evento<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Validar l\u00f3gica y fecha de estado<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Modelar el fragnet del evento<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Insertar en el cronograma<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Recalcular la red<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Comparar hitos y camino cr\u00edtico<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Evaluar mitigaci\u00f3n y responsabilidad<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/g><\/g><\/svg>

L\u00f3gica simplificada de una Time Impact Analysis aplicada a un evento de proyecto<\/figcaption><\/figure>\n\n\n\n

La calidad de la TIA depende de la credibilidad del update seleccionado y de la modelizaci\u00f3n del evento. Si el fragnet exagera la duraci\u00f3n, crea dependencias artificiales o ignora actividades paralelas, el resultado puede sobreestimar el impacto.<\/p>\n\n\n\n

Cu\u00e1ndo TIA tiene m\u00e1s sentido<\/h2>\n\n\n\n

TIA tiende a ser m\u00e1s \u00fatil cuando el proyecto todav\u00eda est\u00e1 en curso, existe un cronograma actualizado confiable y el evento puede representarse mediante actividades y relaciones l\u00f3gicas verificables.<\/p>\n\n\n\n

Es especialmente valiosa cuando la decisi\u00f3n debe tomarse antes del cierre, por ejemplo para evaluar una extensi\u00f3n de plazo, change order, acceso tard\u00edo, atraso de informaci\u00f3n, cambio de proyecto o instrucci\u00f3n que altere la secuencia.<\/p>\n\n\n\n

Pierde fuerza cuando no existen updates confiables, cuando el an\u00e1lisis se realiza mucho despu\u00e9s del evento o cuando la l\u00f3gica del cronograma no representa la ejecuci\u00f3n real. En esos casos, otros m\u00e9todos retrospectivos pueden ser m\u00e1s adecuados.<\/p>\n\n\n\n

TIA no debe ser una simulaci\u00f3n desconectada de la ejecuci\u00f3n<\/h2>\n\n\n\n

Una TIA bien estructurada debe confrontar el modelo con hechos contempor\u00e1neos: fechas reales, frentes disponibles, restricciones, recursos, avance, decisiones y condiciones de acceso.<\/p>\n\n\n\n

Tambi\u00e9n debe considerar la mitigaci\u00f3n. Si el equipo logr\u00f3 resecuenciar actividades, abrir otro frente o anticipar parte del trabajo, el efecto final puede ser menor que el impacto bruto inicialmente proyectado.<\/p>\n\n\n\n

El an\u00e1lisis t\u00e9cnico debe documentar las premisas y limitar las conclusiones a lo que los datos permiten afirmar. En proyectos con baja calidad de planificaci\u00f3n, la incertidumbre metodol\u00f3gica debe aparecer en el dictamen.<\/p>\n\n\n\n

\n

Cuando un atraso relevante debe sustentar una negociaci\u00f3n, extensi\u00f3n de plazo o respuesta a un claim, la metodolog\u00eda debe definirse a partir de la calidad del cronograma y de las evidencias \u2014 no del resultado que una de las partes desea obtener.<\/p>\n\n\n\n

Estructure un an\u00e1lisis t\u00e9cnico de plazo integrado al claim contractual<\/a><\/p>\n<\/div>\n\n\n\n

An\u00e1lisis por ventanas<\/h2>\n\n\n\n

Window Analysis divide el proyecto en per\u00edodos y examina la evoluci\u00f3n del camino cr\u00edtico y de los atrasos en cada ventana. La l\u00f3gica es \u00fatil en proyectos largos en los que la criticidad, la secuencia y los eventos cambian significativamente a lo largo del tiempo.<\/p>\n\n\n\n

El tama\u00f1o de las ventanas puede seguir updates mensuales, hitos o per\u00edodos con caracter\u00edsticas similares. Las ventanas cortas aumentan el detalle, pero exigen datos consistentes; las ventanas amplias pueden ocultar cambios relevantes.<\/p>\n\n\n\n

El an\u00e1lisis debe explicar por qu\u00e9 se eligi\u00f3 determinada divisi\u00f3n y c\u00f3mo se asignaron los eventos a cada per\u00edodo.<\/p>\n\n\n\n

As-planned vs. as-built<\/h2>\n\n\n\n

Comparar la planificaci\u00f3n original con la ejecuci\u00f3n real es intuitivo y puede ofrecer una visi\u00f3n general, pero por s\u00ed solo no demuestra causalidad. La diferencia entre dos fechas no informa qu\u00e9 evento produjo el desv\u00edo ni si el atraso era cr\u00edtico cuando ocurri\u00f3.<\/p>\n\n\n\n

Este tipo de comparaci\u00f3n puede apoyar un diagn\u00f3stico inicial, pero los claims complejos normalmente exigen analizar la l\u00f3gica y la evoluci\u00f3n temporal.<\/p>\n\n\n\n

Collapsed as-built y enfoques retrospectivos<\/h2>\n\n\n\n

Los m\u00e9todos retrospectivos pueden eliminar del as-built determinados eventos para estimar cu\u00e1l habr\u00eda sido la finalizaci\u00f3n \u201cbut for\u201d esos impactos. Esta l\u00f3gica se asocia frecuentemente al collapsed as-built.<\/p>\n\n\n\n

El desaf\u00edo es reconstruir una red l\u00f3gica confiable a partir de la ejecuci\u00f3n real. Si las relaciones entre actividades no est\u00e1n demostradas, la eliminaci\u00f3n de eventos puede crear una condici\u00f3n hipot\u00e9tica alejada de lo que habr\u00eda sido t\u00e9cnicamente posible.<\/p>\n\n\n\n

Ning\u00fan m\u00e9todo debe elegirse \u00fanicamente porque produzca un n\u00famero favorable. El m\u00e9todo debe responder la pregunta con los datos disponibles.<\/p>\n\n\n\n

C\u00f3mo elegir el m\u00e9todo de Delay Analysis<\/h2>\n\n\n\n

La selecci\u00f3n 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\u00e1neos, la complejidad de la l\u00f3gica y la finalidad del an\u00e1lisis.<\/p>\n\n\n\n

El SCL Protocol recomienda que la elecci\u00f3n de la metodolog\u00eda considere la naturaleza del proyecto, la documentaci\u00f3n disponible y la proporcionalidad. En t\u00e9rminos de ingenier\u00eda, esto significa que el m\u00e9todo debe ser defendible antes de ser conveniente.<\/p>\n\n\n\n

Un an\u00e1lisis puede incluso combinar t\u00e9cnicas, siempre que se expliciten los l\u00edmites y no se mezclen premisas incompatibles.<\/p>\n\n\n\n

Eventos de atraso y Claim Management<\/h2>\n\n\n\n

Delay Analysis funciona mejor cuando los eventos ya fueron controlados durante la ejecuci\u00f3n. Claim Management<\/a> crea la trazabilidad de notices, evidencias, decisiones y registros que posteriormente utilizar\u00e1 el an\u00e1lisis de plazo.<\/p>\n\n\n\n

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\u00f3nicos, diarios y logs. Esto aumenta el costo y la incertidumbre.<\/p>\n\n\n\n

Delay Analysis dentro de un claim contractual<\/h2>\n\n\n\n

El claim contractual<\/a> necesita integrar la conclusi\u00f3n temporal con el fundamento contractual. Demostrar 20 d\u00edas de impacto en una red no significa autom\u00e1ticamente tener derecho a 20 d\u00edas de extensi\u00f3n.<\/p>\n\n\n\n

Es necesario confrontar el evento con las cl\u00e1usulas, la matriz de riesgos, los notices, la responsabilidad, la concurrencia de atrasos, la mitigaci\u00f3n y las condiciones espec\u00edficas del contrato.<\/p>\n\n\n\n

El an\u00e1lisis del cronograma informa el efecto t\u00e9cnico. El entitlement determina c\u00f3mo se tratar\u00e1 ese efecto contractualmente.<\/p>\n\n\n\n

Concurrency: los atrasos simult\u00e1neos exigen un an\u00e1lisis cuidadoso<\/h2>\n\n\n\n

Concurrency no debe tratarse \u00fanicamente como la presencia de dos problemas en el mismo mes. La cuesti\u00f3n es verificar si eventos bajo responsabilidades distintas afectaron simult\u00e1neamente el camino cr\u00edtico o la finalizaci\u00f3n relevante.<\/p>\n\n\n\n

La definici\u00f3n y el efecto jur\u00eddico de concurrency var\u00edan seg\u00fan el contrato y la legislaci\u00f3n aplicable. El an\u00e1lisis de ingenier\u00eda debe limitarse a demostrar cronolog\u00eda, criticidad y superposici\u00f3n t\u00e9cnica, dejando la consecuencia jur\u00eddica a la interpretaci\u00f3n competente.<\/p>\n\n\n\n

Los cronogramas poco actualizados dificultan esta evaluaci\u00f3n porque ocultan la migraci\u00f3n de criticidad entre frentes.<\/p>\n\n\n\n

Float y responsabilidad por el tiempo disponible<\/h2>\n\n\n\n

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\u00edtica en cr\u00edtica.<\/p>\n\n\n\n

El an\u00e1lisis debe mostrar el float disponible en el momento del evento y c\u00f3mo evolucion\u00f3. No es adecuado presumir que todo consumo de float equivale a una extensi\u00f3n de plazo.<\/p>\n\n\n\n

Tambi\u00e9n es importante verificar restricciones artificiales, lags excesivos y calendarios que puedan distorsionar el c\u00e1lculo.<\/p>\n\n\n\n

Data date, actualizaci\u00f3n y estado real<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Antes de utilizar un update en Delay Analysis, conviene verificar fechas reales, porcentajes, remaining duration, relaciones abiertas, actividades fuera de secuencia, constraints e hitos.<\/p>\n\n\n\n

Una auditor\u00eda del cronograma no es burocracia: es una precondici\u00f3n para confiar en el modelo.<\/p>\n\n\n\n

\n

Cuanto antes se gobiernen conjuntamente cronograma, alcance, interfaces y eventos contractuales, menor ser\u00e1 la necesidad de reconstrucci\u00f3n forense al cierre y mayor la capacidad de decidir mientras todav\u00eda existe margen para mitigaci\u00f3n.<\/p>\n\n\n\n

Integre plazo, alcance y evidencias en la Gesti\u00f3n de Contratos, Alcance y Entregables<\/a><\/p>\n<\/div>\n\n\n\n

Auditar el cronograma antes de cualquier conclusi\u00f3n<\/h2>\n\n\n\n

Antes de aplicar TIA, Window Analysis o cualquier m\u00e9todo retrospectivo, el cronograma debe auditarse como un modelo t\u00e9cnico. El an\u00e1lisis de atraso presupone que las relaciones, fechas y avance representan razonablemente la ejecuci\u00f3n; si esta premisa falla, el resultado matem\u00e1tico puede amplificar errores de origen.<\/p>\n\n\n\n

La auditor\u00eda debe examinar l\u00f3gica abierta, actividades sin predecesora o sucesora cuando no sea justificable, constraints r\u00edgidas, lags elevados, calendarios incoherentes, duraciones remanentes incompatibles con el avance, actividades fuera de secuencia y cambios de l\u00f3gica entre updates. Tambi\u00e9n es necesario verificar si los hitos contractuales fueron modelados correctamente y si la fecha de estado se aplic\u00f3 de manera consistente.<\/p>\n\n\n\n

Control<\/td>Riesgo para Delay Analysis<\/td>Verificaci\u00f3n<\/td><\/tr>
l\u00f3gica incompleta<\/td>crea un camino cr\u00edtico artificial<\/td>predecesoras, sucesoras y relaciones<\/td><\/tr>
constraints r\u00edgidas<\/td>impiden que la red reaccione al evento<\/td>tipo, fecha y justificaci\u00f3n de la restricci\u00f3n<\/td><\/tr>
avance inconsistente<\/td>distorsiona remaining duration y criticidad<\/td>fechas reales, porcentajes y registros de campo<\/td><\/tr>
cambio de l\u00f3gica<\/td>puede reescribir retrospectivamente el plan<\/td>comparaci\u00f3n entre updates sucesivos<\/td><\/tr>
calendarios<\/td>modifican duraci\u00f3n y float sin un cambio aparente<\/td>jornadas, feriados, turnos y excepciones<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Una inconsistencia no vuelve autom\u00e1ticamente inutilizable el cronograma. El analista debe evaluar la materialidad, documentar ajustes cuando sean necesarios y explicar c\u00f3mo cada limitaci\u00f3n afecta el grado de confianza de la conclusi\u00f3n. En algunos casos, determinados per\u00edodos pueden analizarse con mayor confiabilidad que otros.<\/p>\n\n\n\n

C\u00f3mo construir un fragnet t\u00e9cnicamente defendible<\/h2>\n\n\n\n

En TIA, el fragnet representa la l\u00f3gica adicional creada por el evento. Su construcci\u00f3n exige m\u00e1s que insertar una actividad con duraci\u00f3n igual al per\u00edodo reclamado. Es necesario modelar el mecanismo real de impacto: qu\u00e9 actividades fueron bloqueadas, qu\u00e9 nuevas etapas surgieron, qu\u00e9 aprobaciones pasaron a ser necesarias y d\u00f3nde se conecta el evento con la red existente.<\/p>\n\n\n\n

La duraci\u00f3n del fragnet debe estar sustentada por registros contempor\u00e1neos o por una estimaci\u00f3n t\u00e9cnica demostrable. Si una revisi\u00f3n de proyecto consumi\u00f3 diez d\u00edas, por ejemplo, es necesario distinguir tiempo de elaboraci\u00f3n, an\u00e1lisis, aprobaci\u00f3n, movilizaci\u00f3n y efecto efectivo sobre el frente cr\u00edtico. Sumar todos estos per\u00edodos sin verificar superposici\u00f3n puede sobreestimar el impacto.<\/p>\n\n\n\n

Las relaciones l\u00f3gicas tambi\u00e9n deben justificarse. Conectar el evento directamente a un hito final puede producir un efecto matem\u00e1tico sin representar el proceso ejecutivo. El fragnet debe entrar en la red donde realmente ocurri\u00f3 la consecuencia, preservando actividades paralelas y alternativas disponibles.<\/p>\n\n\n\n

Despu\u00e9s de la inserci\u00f3n, la comparaci\u00f3n debe mostrar no solo la diferencia de la fecha final, sino tambi\u00e9n el cambio del camino cr\u00edtico, el consumo de float, las actividades que pasaron a controlar el hito y eventuales efectos absorbidos por la l\u00f3gica existente.<\/p>\n\n\n\n

Atraso excusable, compensable y no excusable: separar efecto de consecuencia<\/h2>\n\n\n\n

La clasificaci\u00f3n contractual de un atraso no debe confundirse con su medici\u00f3n t\u00e9cnica. Delay Analysis puede demostrar que determinado evento desplaz\u00f3 un hito; aun as\u00ed, el contrato puede atribuir consecuencias diferentes seg\u00fan la responsabilidad, la matriz de riesgos y las cl\u00e1usulas aplicables.<\/p>\n\n\n\n

En la terminolog\u00eda ampliamente utilizada en contratos de construcci\u00f3n, un atraso excusable puede justificar una extensi\u00f3n de plazo, mientras que un atraso compensable puede, adem\u00e1s del tiempo, sustentar determinados costos adicionales. Un atraso no excusable permanece bajo responsabilidad de la parte que asumi\u00f3 el riesgo o produjo el evento. La definici\u00f3n concreta depende del contrato y de la legislaci\u00f3n aplicable; por lo tanto, el an\u00e1lisis de ingenier\u00eda debe evitar transformar estas categor\u00edas en una conclusi\u00f3n jur\u00eddica autom\u00e1tica.<\/p>\n\n\n\n

Esta separaci\u00f3n mejora el dictamen. Primero se demuestra el efecto temporal: evento, per\u00edodo, actividad, criticidad e impacto neto. Despu\u00e9s se aplica la lectura contractual para determinar si ese efecto es reconocible como extensi\u00f3n, compensaci\u00f3n, riesgo asumido u otro tratamiento.<\/p>\n\n\n\n

En proyectos con varios eventos, la clasificaci\u00f3n tambi\u00e9n ayuda a evitar compensaciones cruzadas mal justificadas. Dos atrasos pueden ocurrir en el mismo per\u00edodo y tener consecuencias contractuales distintas, aunque ambos aparezcan en la evoluci\u00f3n de la red.<\/p>\n\n\n\n

La extensi\u00f3n de plazo y los costos de prolongaci\u00f3n no son la misma demostraci\u00f3n<\/h2>\n\n\n\n

Demostrar el derecho t\u00e9cnico a una extensi\u00f3n de plazo no determina autom\u00e1ticamente el valor de los costos de prolongaci\u00f3n. El primer an\u00e1lisis responde cu\u00e1ntos d\u00edas determinados eventos afectaron la finalizaci\u00f3n o hitos relevantes. El segundo debe demostrar qu\u00e9 costos adicionales resultaron del aumento efectivo de la duraci\u00f3n.<\/p>\n\n\n\n

Los costos de prolongaci\u00f3n pueden involucrar equipo de gesti\u00f3n, instalaciones temporales, seguridad, equipos, alquileres, seguros, administraci\u00f3n de campo y otros \u00edtems dependientes del tiempo. Sin embargo, cada componente debe confrontarse con el per\u00edodo real, la estructura movilizada y los mecanismos ya remunerados por el contrato.<\/p>\n\n\n\n

Tampoco es adecuado multiplicar autom\u00e1ticamente un costo diario promedio por el n\u00famero de d\u00edas 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.<\/p>\n\n\n\n

Por eso, los claims robustos tratan plazo y quantum como an\u00e1lisis conectados, pero distintos. El cronograma establece la ventana temporal causal; los registros de costos demuestran lo que efectivamente ocurri\u00f3 dentro de ella. La convergencia de ambas l\u00edneas produce una conclusi\u00f3n m\u00e1s defendible que una simple extrapolaci\u00f3n financiera a partir de los d\u00edas calculados.<\/p>\n\n\n\n

Evidencias que sustentan un an\u00e1lisis de atraso<\/h2>\n\n\n\n

El cronograma por s\u00ed solo rara vez es suficiente. El an\u00e1lisis debe cruzar la red con documentos de ejecuci\u00f3n.<\/p>\n\n\n\n

Actas, RFIs, diarios, informes, registros fotogr\u00e1ficos, entregables de proyecto, liberaciones de acceso, movilizaci\u00f3n, procurement, logs de equipos, pruebas y correspondencias ayudan a definir inicio, fin y mecanismo de cada evento.<\/p>\n\n\n\n

Esta triangulaci\u00f3n reduce el riesgo de modelar fechas \u00fanicamente a partir de la narrativa posterior de las partes.<\/p>\n\n\n\n

Atraso de proveedor e interfaces entre contratos<\/h2>\n\n\n\n

En proyectos con m\u00faltiples paquetes, un proveedor puede atrasar a otro sin que exista una relaci\u00f3n contractual directa entre ellos. El an\u00e1lisis debe rastrear la interfaz: qu\u00e9 entrega era predecesora, cu\u00e1ndo era necesaria, cu\u00e1ndo fue disponibilizada y qu\u00e9 alternativa exist\u00eda.<\/p>\n\n\n\n

La Gesti\u00f3n de Contratos, Alcance y Entregables<\/a> ayuda a formalizar estas fronteras antes de que la responsabilidad se vuelva difusa.<\/p>\n\n\n\n

Mitigaci\u00f3n, resecuenciaci\u00f3n y plan de recuperaci\u00f3n<\/h2>\n\n\n\n

Cuando un evento amenaza un hito, el equipo puede resecuenciar, aumentar recursos, cambiar turnos, liberar frentes parciales o modificar el m\u00e9todo ejecutivo. Estas acciones deben reflejarse en el an\u00e1lisis.<\/p>\n\n\n\n

Una mitigaci\u00f3n razonable no significa eliminar todo impacto a cualquier costo. El dictamen debe distinguir medidas ordinarias de acciones extraordinarias de aceleraci\u00f3n y registrar sus efectos.<\/p>\n\n\n\n

Un plan de recuperaci\u00f3n tampoco borra autom\u00e1ticamente un atraso ya ocurrido; muestra c\u00f3mo la organizaci\u00f3n pretende controlar el resto de la ejecuci\u00f3n.<\/p>\n\n\n\n

C\u00f3mo presentar la conclusi\u00f3n de una Delay Analysis<\/h2>\n\n\n\n

Una conclusi\u00f3n \u00fatil no debe limitarse a indicar \u201cX d\u00edas de atraso\u201d. Debe explicar evento, per\u00edodo, cronograma de referencia, m\u00e9todo, camino cr\u00edtico, premisas, resultado, concurrencias, mitigaci\u00f3n y limitaciones.<\/p>\n\n\n\n

Una tabla por evento suele ser m\u00e1s \u00fatil que una narrativa \u00fanica:<\/p>\n\n\n\n

Evento<\/td>Per\u00edodo<\/td>Actividad afectada<\/td>Criticidad<\/td>Impacto neto<\/td>Evidencia<\/td>Observaci\u00f3n<\/td><\/tr>
cambio A<\/td>fechas verificadas<\/td>paquete\/sistema<\/td>cr\u00edtica o no<\/td>d\u00edas<\/td>documentos<\/td>premisas<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

La transparencia metodol\u00f3gica permite que otro equipo reproduzca el razonamiento y cuestione premisas espec\u00edficas sin rechazar todo el an\u00e1lisis.<\/p>\n\n\n\n

Errores frecuentes en los an\u00e1lisis de atraso<\/h2>\n\n\n\n

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\u00f3n del camino cr\u00edtico. Tambi\u00e9n son problem\u00e1ticos los fragnets sin base factual, los updates no auditados, la ausencia de fecha de estado y la mezcla entre atraso e improductividad.<\/p>\n\n\n\n

Otro error com\u00fan es presentar un resultado matem\u00e1tico como conclusi\u00f3n contractual. Delay Analysis demuestra impacto temporal; entitlement, riesgos y cl\u00e1usulas determinan la consecuencia de ese impacto.<\/p>\n\n\n\n

Consideraciones finales<\/h2>\n\n\n\n

Delay Analysis es una disciplina de causalidad temporal. Su objetivo es explicar, mediante cronograma y evidencias, c\u00f3mo los eventos modificaron la secuencia y los hitos del proyecto. Time Impact Analysis es una herramienta importante dentro de este campo, especialmente para an\u00e1lisis contempor\u00e1neos o prospectivos, pero no es adecuada para todos los casos.<\/p>\n\n\n\n

La calidad de la conclusi\u00f3n depende menos del software utilizado y m\u00e1s de la calidad de la baseline, de los updates, de la modelizaci\u00f3n del evento y de los registros contempor\u00e1neos. M\u00e9todo y datos deben ser compatibles.<\/p>\n\n\n\n

Cuando el an\u00e1lisis 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\u00f3n de plazo, mitigaci\u00f3n y negociaci\u00f3n.<\/p>\n\n\n\n

Referencias t\u00e9cnicas<\/summary>\n

[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<\/a><\/p>\n\n\n\n

[2] AACE INTERNATIONAL. Recommended Practices. Biblioteca de referencias t\u00e9cnicas, incluidas pr\u00e1cticas de an\u00e1lisis forense de cronogramas. Disponible en: https:\/\/web.aacei.org\/resources\/recommended-practices<\/a><\/p>\n\n\n\n

[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\/<\/a><\/p>\n<\/details>\n\n\n\n

Preguntas frecuentes<\/summary>\n
\u00bfQu\u00e9 es Delay Analysis en ingenier\u00eda?<\/strong>

Es el an\u00e1lisis t\u00e9cnico que utiliza cronogramas y evidencias para determinar c\u00f3mo determinados eventos afectaron o pueden afectar el camino cr\u00edtico, los hitos y la fecha de finalizaci\u00f3n de un proyecto.<\/p><\/div>

\u00bfQu\u00e9 es Time Impact Analysis?<\/strong>

Es un m\u00e9todo que modela un evento o fragnet en un cronograma actualizado para evaluar su efecto probable sobre la red, el camino cr\u00edtico y los hitos.<\/p><\/div>

\u00bfTIA es el \u00fanico m\u00e9todo de an\u00e1lisis de atraso?<\/strong>

No. Existen enfoques prospectivos y retrospectivos, incluidos an\u00e1lisis por ventanas, comparaciones as-planned vs. as-built y m\u00e9todos basados en el as-built. La elecci\u00f3n depende de los datos y de la finalidad.<\/p><\/div>

\u00bfCu\u00e1l es la diferencia entre delay y disruption?<\/strong>

Delay est\u00e1 asociado al tiempo y a la finalizaci\u00f3n; disruption est\u00e1 asociada a la p\u00e9rdida de productividad y eficiencia. Un mismo evento puede producir ambos efectos.<\/p><\/div>

\u00bfUn cronograma baseline es suficiente para demostrar un atraso?<\/strong>

No. El an\u00e1lisis debe considerar updates, el camino cr\u00edtico contempor\u00e1neo, eventos, evidencias de campo, mitigaci\u00f3n y condiciones contractuales.<\/p><\/div>

\u00bfDelay Analysis define autom\u00e1ticamente el derecho a una extensi\u00f3n de plazo?<\/strong>

No. El an\u00e1lisis demuestra el efecto temporal. El entitlement depende del contrato, la matriz de riesgos, notices, responsabilidad y reglas aplicables.<\/p><\/div><\/div>\n<\/details>\n\n\n\n

Materiales t\u00e9cnicos complementarios<\/summary>\n

Contenidos principales sobre el tema<\/h4>\n\n