Análisis de Retrasos en Proyectos

El siguiente articulo pretende introducir brevemente las técnicas utilizadas en el análisis de retrasos
que se utilizan frecuentemente y que están reconocidas por organismos tales como la «Society of
Construction Law» y la AACEI, que son los organismos más influyentes a la hora de establecer las
técnicas a aplicar para cuantificar los retrasos en un proyecto, así como determinar la
responsabilidad de los mismos.

En definitiva, lo que con estas técnicas se busca es demostrar ante un Tribunal o en una
negociación con un cliente cuáles fueron las causas que han llevado a que un proyecto no cumpla
con la fecha contractual de finalización. En el caso de que dichas causas sean producidas por el
cliente, el contratista podría reclamar una extensión para la finalización del proyecto, ser eximido de
daños y perjuicios y solicitar además una indemnización por el aumento de los costes ocasionados.

Impacted as Planned (IAP)

La primera técnica, así como la más común, es la conocida como «Impacted as Planned». Esta
técnica se utiliza para ayudar a demostrar la extensión en plazo de un proyecto, cuando tenemos un
programa aprobado por el contratista y por el cliente. Funciona muy bien cuando el evento de
demora se produce al inicio del proyecto.

Es bastante criticada debido a que no tiene en cuenta cuál es el estado del proyecto en el momento
en el que tiene lugar la demora, es decir no tiene en cuenta los posibles retrasos que arrastra el
proyecto.

Si se pretende utilizar para reclamar los costes incurridos durante la prolongación de la ejecución, es
necesario que las duraciones de los eventos se basen en datos as-built ya que «la compensación por
prolongación no debe ser pagada por nada que no sea el trabajo realmente realizado, el tiempo
realmente tomado o la pérdida y/o el gasto realmente sufrido». En definitiva, para reclamar un
coste de prolongación es necesario aportar datos reales para justificar los gastos incurridos.

Esta técnica no es válida para identificar la concurrencia real. Por concurrencia se entiende que dos
eventos de retraso sucedan a la vez, que ambos tengan consecuencias en la fecha fin de proyecto y
que sean responsabilidad del contratista y del cliente, respectivamente.

Fortalezas
• No es necesario tener un programa as-built.
• Es fácil de implementar, no requiere demasiado tiempo y tiene bajo coste.
• Funciona bien en los proyectos con lógica prescriptiva, es decir cuando los trabajos deben
ejecutarse de una manera determinada.
• No se necesitan recursos altamente cualificados.

Debilidades
• No considera la situación del Proyecto cuando ocurrió el impacto (es posible que en ese
momento el proyecto ya estuviera retrasado por otras causas).
• No considera medidas de mitigación ni aceleración tomadas por el contratista para intentar
reducir los efectos de los retrasos.
• Toda la holgura que tiene el programa es consumida por la parte que genera el evento de
retraso.
Análisis de Retrasos en Proyectos

• Los resultados son muy teóricos y el ejercicio puede dar resultados poco realistas, esto es
más pronunciado cuando hay un alto porcentaje de relaciones preferenciales1.

Cuándo es apropiado usar este método

Las circunstancias en las que este método es apropiado están relacionadas con sus puntos fuertes y
son las siguientes:

• No existe un listado de programas actualizados ni suficientes datos históricos como para

crear un programa as-built.
• Existe un programa baseline aprobado por el cliente, con todo el alcance de los trabajos y
además la ejecución de los trabajos sigue una secuencia definida en el programa baseline.
• El contratista quiere mostrar cuál es el efecto de una Orden de Cambio al cliente en una
etapa temprana del cambio. Esto es debido a que normalmente los efectos que aparecen en
IAP son muy dramáticos y suelen ser útiles para ejercer presión sobre el cliente. Este
método ofrece una estimación de los efectos sobre la fecha de finalización del proyecto.
• El programa ha sido aprobado por todas las partes y el evento de retraso se produce al
inicio del proyecto (situación óptima).

Aplicación del método IAP

La implementación del IAP se basa en un programa baseline aprobado por ambas partes y muestra
cuál era la intención original del contratista en cuanto a la ejecución del proyecto.

Una vez que este archivo está disponible, la siguiente tarea es identificar el evento de retraso,
seguidamente se calculará la duración de los efectos y, una vez obtenida la duración, se insertará en
el programa baseline aprobado en forma de tarea o tareas (fragnet), o bien aumentando la duración de
algunas actividades. Una vez se llevan a cabo las tareas anteriores, el siguiente paso es ejecutar el
programa y observar los efectos en la nueva fecha fin del proyecto. La diferencia entre esta y la
fecha final original representa los efectos del cambio en tiempo y, por lo tanto, la extensión de
tiempo que se le reclama al cliente.

Para implementar un método IAP contemporáneamente (donde no se tienen los registros

históricos) los efectos son estimaciones y por ello teóricos, no obstante este ejercicio es útil para
evaluar los efectos de una Orden de Cambio y mostrárselos al cliente. Además de ser útil en las
etapas preliminares de una reclamación.

Este ejercicio no generaría derecho de aumento en el plazo de ejecución del proyecto.

En el caso de que se vaya a aplicar este método una vez sobrepasada la fecha fin del proyecto y con
datos as-built (es decir, de manera forense) este ejercicio si generaría derechos de extensión de plazo.

Time Impact Analysis (TIA)

El siguiente método es una evolución del IAP. Además, es el mejor método para determinar la
cantidad de extensión de tiempo que se le debería conceder a un contratista en el momento en que
ocurrió un evento de retraso. Los resultados de la aplicación de este método generan derechos.
Debido a que el TIA considera cuál es el estado del proyecto en el momento en el que tuvo lugar el
evento de retraso y además permite añadir por separado fragnets que representan el evento de retraso
del contratista y fragnets que representan los eventos de retraso del cliente, es el mejor método a
utilizar en caso de concurrencia, aceleración y disrupción2.

1
Las relaciones preferenciales son aquellas que siguen los trabajos que se pueden ejecutar de varias maneras y
no tienen que seguir un orden preestablecido.
2
La disrupción se define como es una pérdida de eficiencia en la ejecución de los trabajos por motivos ajenos
al contratista. Ejemplos de disrupción serían limitación de acceso a la zona de obra o limitación del uso de
suministros que contractualmente deben facilitarse por parte del cliente.
© Natalia Barroso 2017 2
Análisis de Retrasos en Proyectos

Si se quieren reclamar los gastos por la prolongación de tiempo, se necesita utilizar datos as-built ya
que se deben reclamar los costes por prolongación por las pérdidas y los gastos ya incurridos.

Fortalezas
• Tiene en cuenta la situación del proyecto en el momento en que ocurre el evento.
• Puede identificar concurrencia aproximada.
• Se puede llevar a cabo simultáneamente a medida que se ejecuta el proyecto
• No requiere de un programa as-built.
• Este método es muy útil cuando hay una disputa donde hay concurrencia, así como
aceleración y disrupción.
• De acuerdo con el Protocolo SCL es el mejor método para determinar el aumento del
plazo de ejecución de los trabajos (EOT) que el cliente debería haber concedido a un
contratista en el momento en que ocurrió el evento de retraso.
• Este método puede ser un método extremadamente convincente a la hora de demostrar el
impacto del retraso en el programa de un contratista.

Debilidades
• Se necesitan recursos especializados debido a que para aplicarlo correctamente es necesario
actualizar el programa inmediatamente antes de que ocurra el evento de retraso, y además
es necesario contar con la información histórica para llevar a cabo la actualización para
garantizar la precisión.
• Se producen resultados teóricos basados en hipótesis.
• Si el análisis no está soportado con datos de obra, los resultados del estudio pueden ser
poco creíbles.

Cuándo es apropiado usar este método

Este método es muy apreciado en disputas complejas, ya que tiene en cuenta cuál era el estado del
proyecto en el momento en que ocurrió el evento. Además, con este método se puede identificar la
concurrencia y la disrupción.

Para poder aplicarlo es necesario tener los ficheros nativos de las actualizaciones de los programas
(ya que esa es la base de este análisis) y contar con recursos especializados en el manejo de
programas de planificación.

Requiere disponer de información histórica, si bien no es necesario tener un programa as-built.

Aplicación del método

Para aplicar este método es necesario enumerar todos los eventos de retraso identificados durante el
proyecto, con sus duraciones, actividades predecesoras-sucesoras, fechas, etc. e identificar el
responsable de cada uno de los eventos. Esta tarea requiere basarse en circunstancias y obligaciones
contractuales.

También es necesario obtener los datos de progreso para todas las actividades del programa antes
de la fecha de inicio del evento de retraso. Con todo ello se busca tener una serie de programas pre-
impactados que más adelante se utilizarán en el análisis.

Es necesario comprobar la fecha de finalización prevista antes de insertar cualquier evento de

retraso y, a continuación, convertir cada evento en un fragnet. Si este ejercicio se hace de manera
prospectiva, es decir, antes de que se conozcan los efectos las duraciones, estas se basarán en
estimaciones, mientras si se hace de manera retrospectiva, las secuencias y duraciones reales
permitirán reducir los resultados teóricos. El fragnet en sí es un grupo de actividades que representan
el evento de retraso.

© Natalia Barroso 2017 3

Análisis de Retrasos en Proyectos

Una vez finalizada esta fase, se insertan los fragnets por orden cronológico en sus respectivos
programas y se van anotando los efectos en un registro para comprobar el posible efecto de cada
uno, así como el global.

Collapse as-Built
Este método se basa en otro modelo dinámico como los anteriores, con la gran diferencia de que
en lugar de añadir los fragnets aquí se eliminan del modelo y se calcula cuál hubiera sido la fecha fin
de proyecto de no haber sucedido dichos hechos. Esto genera, además, derechos de extensión en
plazo.

Este método se basa en datos históricos que reflejan costes y retrasos incurridos y, por lo tanto, es
válido para reclamar pérdidas y gastos. No obstante, no es válido para identificar acciones de
concurrencia, mitigación y aceleración realizadas durante la vida del proyecto, ya que esta técnica se
basa en la reconstrucción de un programa as-built.

Fortalezas
• Es muy gráfico y fácil de entender.
• Se basa en un modelo de programa as-built que muestra cuál habría sido la fecha fin de
proyecto de un proyecto de no haber sido por la aparición de un evento de retraso en
particular.
© Natalia Barroso 2017 4
Análisis de Retrasos en Proyectos

• No requiere tener un programa baseline aprobado, ni sus actualizaciones.

Debilidades
• Es muy laborioso, debido a que es necesario desarrollar un programa as-built con sus
relaciones.

Cuándo es apropiado usar este método

Este método se debe de utilizar si el proyecto tiene un bajo número de actividades, un buen
programa as-built y una secuencia de ejecución de los trabajos determinada.

Es un método que raramente se utiliza, pero que es adecuado cuando los eventos de retraso se
producen al final del proyecto y, sobre todo, en proyectos lineales tales como oleoductos o túneles.
Ello es debido a que uno de los pilares sobre los que se basa este método es la lógica y, por lo tanto,
si la lógica muestra las relaciones preferenciales entre actividades, los resultados serán criticados y el
ejercicio rechazado. Por contra, si el ejercicio se ajusta a las situaciones previamente descritas
constituirá una herramienta poderosa que demuestra claramente cuál habría sido el final del
proyecto en el caso de que un evento en particular no hubiera sucedido, ya que se basa en
principios simples y fáciles de entender.

Aplicación del método

Su aplicación se basa en la recreación de un modelo que representa el programa as-built en el cual se
incluyen los eventos de retraso que se muestran en las barras pintadas en amarillo. A continuación,
se eliminan estas barras amarillas (los eventos de retraso) y se ejecuta el programa observando cuál
habría sido la fecha fin de proyecto de no haber sido por esos retrasos. Si esos retrasos son por
causa del cliente, el contratista tendría derecho a una extensión de plazo y a ser eximido de daños y
perjuicios por dicho retraso.

© Natalia Barroso 2017 5

Análisis de Retrasos en Proyectos

As Planned vs As Built
El último de todos los métodos es el As Planned vs As Built y la gran diferencia con los demás es que
para su ejecución no se utiliza un programa dinámico, sino que se toman los programas baseline y as-
built y se lleva a cabo un análisis observando las diferencias entre ambos. Es por ello que no es
necesario tener los ficheros nativos. Este método es ampliamente utilizado para identificar y
reclamar concurrencia y en ocasiones se utiliza de forma preferente por analistas con conocimientos
limitados de software de planificación.

Este método requiere definir una ruta crítica para poder reclamar una indemnización por demora, y
puede generar derechos por extensión de plazo si se aportan datos históricos que podrán
presentarse en juicios y arbitrajes.

Fortalezas
• Es un método muy bueno cuando no se tienen los archivos nativos de los programas, sino
que hay copias impresas, fotografías, correspondencia, informes y actas de las reuniones.
• Las conclusiones son soportadas con registros de obra y hechos.
• Debido a que este no es un modelo dinámico, se puede mantener un registro de sus
supuestos y, si fuera necesario, se puede cambiar fácilmente de supuesto.
• Es un método fácil de comprender.
• No es necesario tener recursos con un alto conocimiento de software de planificación.
• Los resultados no se basan en la manipulación de los programas con un software de
planificación y esto es recibido positivamente dado que las personas implicadas en las
evaluaciones de las reclamaciones tienden a no confiar demasiado en los resultados que
provienen de la manipulación de los programas y, por ello, prefieren un ejercicio basado en
hechos soportados por documentación as-built.

Debilidades
• Requiere un analista experto para deducir la ruta crítica as-built.
• Es necesario tener un programa as-built, es decir, la última actualización del programa en el
momento de finalización del proyecto. Esto no siempre es posible debido a la
desmovilización de los recursos a medida que finalizan los proyectos.
• Para desarrollar este método es necesario tener registros as-built.
• El programa as-built tiene que ser razonable y debe de ser aprobado por todas las partes.
• Debido al hecho de que este método se sustenta en una narrativa basada en la comparación
de un programa previsto frente al real, es probable que aumente la complejidad a medida
que crecen el número de causas y efectos.

© Natalia Barroso 2017 6

Análisis de Retrasos en Proyectos

• Al comienzo del proyecto lo habitual es que los programas iniciales y baselines se desarrollen
con menos información y detalle y, a medida que avanza el proyecto y se va teniendo más
información, se incorpora en el programa en forma de actividades. Esto significa que al
final del proyecto se tendrá un programa baseline que no se corresponde con el de fin de
obra y por lo tanto, dificulta o incluso imposibilita la comparación entre ambos.

Cuándo es apropiado usar este método

De acuerdo con su naturaleza, este método es apropiado cuando la línea base ha sido aprobada, no
ha sufrido muchos cambios y se cuenta con analistas experimentados y con excelentes habilidades
narrativas. Además, dado que se basa en hechos, su aplicación requiere tener fotografías, actas de
reuniones y correspondencia.

Aplicación del método

Las diferencias en la aplicación de este método dependen de los resultados que se desean obtener.
No es un modelo dinámico, es decir, se basa en la comparación observacional de dos programas.
Por ello, si el objetivo es un EOT, se debe demostrar que se ha producido un aumento de la
duración de las actividades que están en la ruta crítica y demostrar con datos históricos que las
actividades que se han retrasado pertenecían a la ruta crítica.
En el caso de que se persiga únicamente una indemnización por aumento del precio debido a la
prolongación, no es necesario identificar la ruta crítica, es suficiente con identificar las actividades
que ha incrementado su coste debido al aumento de la duración, y además es necesario comparar
dicha duración con la planeada para poder justificar el ejercicio.

En definitiva, la elección del método a utilizar en un análisis de demora depende de la información

y recursos de los que se disponga, así como en la fase del proyecto.

© Natalia Barroso 2017 7

Análisis de Retrasos en Proyectos

Bibliografía

AACE International Recommended Practice No. 29R-03. AACE International. 2009.: AACE,
Inc., 2009.

Barnes, Ali D. Haidar and Peter. 2014. Delay and Disruption Claims in Construction.
London : ICE Publishing, 2014.

Caletka, P. J. Keane & A. F. Caletka. 2008. Delay Analysis In Construction Contracts. :

Blackwell Publishing Ltd., 2008.

Society of Construction Law. 2015. Rider 1 to the Society of Construction Law and Disruption
Protocol. July de 2015.

© Natalia Barroso 2017 8