Time Impact Analysis: cómo medir el efecto de un atraso

Cuando ocurre un evento que puede atrasar el proyecto, sea una orden de cambio, una interferencia no prevista o un permiso que no llega, la pregunta inmediata es cuánto afecta la fecha de término. El análisis de impacto en el tiempo, conocido por su nombre en inglés, Time Impact Analysis o TIA, es la técnica más usada para responderla.

Qué dice la práctica recomendada 52R-06

AACE International describe el método en su práctica recomendada 52R-06, Prospective Time Impact Analysis – As Applied in Construction, cuya revisión vigente es del 4 de mayo de 2017.

La 52R-06 define el TIA como una técnica de análisis de cronograma prospectiva, que mira hacia adelante: agrega uno o más eventos modelados a un cronograma no impactado para determinar su efecto potencial sobre la ruta más larga y, por lo tanto, sobre el término del proyecto. Se realiza mientras el proyecto está en curso, en un contexto cercano al tiempo real.

Dos precisiones de la práctica son importantes. La primera: el TIA trata el tiempo, no el costo. El efecto en plazo se cuantifica primero y las consecuencias de costo se determinan después. La segunda: el TIA retrospectivo, hecho una vez ejecutado el trabajo, no suele ser necesario durante la obra, y la propia 52R-06 lo remite a la práctica 29R-03 de análisis forense.

El fragnet

El corazón del método es el fragnet, un fragmento de red: el conjunto de actividades, duraciones y relaciones lógicas que representa el evento. Si el mandante ordena reubicar una sala eléctrica, el fragnet puede incluir el rediseño, su revisión y aprobación, la compra de materiales adicionales y la ejecución de la obra modificada, cada una con su duración y enlazada a las actividades del cronograma que afecta.

Un fragnet bien construido cumple tres condiciones:

• Sus duraciones tienen respaldo. Un plazo de aprobación surge de lo que realmente toma aprobar en ese proyecto, no de un número conveniente.
• Su lógica es explícita. Se ve qué actividades del cronograma espera y cuáles detiene.
• Está vinculado a registros. La orden, la fecha en que se conoció el evento y la correspondencia que lo documenta.

Los pasos, en la práctica

Cada contrato puede exigir detalles propios, pero un TIA sigue en general esta secuencia:

1. Elegir el cronograma de referencia. Es la última actualización aceptada antes del evento, con el avance real a esa fecha de corte. Insertar el evento en el programa base original, ignorando lo ocurrido desde entonces, distorsiona el resultado.
2. Construir el fragnet que representa el evento.
3. Insertarlo en el cronograma de referencia, enlazado a las actividades afectadas.
4. Recalcular y comparar la fecha de término, y los hitos contractuales si corresponde, con y sin el evento.
5. Documentar los supuestos, para que otro analista pueda reproducir el resultado.

La diferencia entre las dos fechas es el efecto estimado del evento sobre el plazo.

Por qué hacerlo durante la obra

El valor del TIA está en su oportunidad. Hecho a tiempo, permite acordar un ajuste de plazo antes de que el trabajo afectado se ejecute por completo, cuando todavía hay decisiones que tomar: acelerar, resecuenciar o aceptar un nuevo término.

La segunda edición del Protocolo de la Society of Construction Law apunta en la misma dirección: propone que el efecto prospectivo de los atrasos se determine de forma contemporánea usando el método TIA. Patrick Weaver, en su revisión del Protocolo, equipara el time impact analysis del SCL con el protocolo MIP 3.7 de AACE, modelado aditivo sobre bases múltiples. Cómo encaja en el conjunto de métodos lo explicamos en la clasificación AACE 29R-03.

En los contratos de obra pública en Chile hay además una razón de calendario: el Reglamento para Contratos de Obras Públicas (DS 75) exige justificar por escrito los atrasos por fuerza mayor o caso fortuito dentro de 30 días desde que se producen. Un TIA preparado a tiempo es el respaldo técnico de esa justificación. Lo detallamos en qué exige el DS 75 para un aumento de plazo.

Errores frecuentes

• Usar un cronograma de referencia sin actualizar, o con lógica incompleta.
• Inflar las duraciones del fragnet para asegurar días.
• Ignorar atrasos propios que ya estaban en la actualización, lo que abre la discusión sobre atrasos concurrentes.
• Confundir consumo de holgura con atraso: si el evento se absorbe dentro de la holgura disponible, no mueve el término.