Existen varias técnicas de análisis de retrasos para informes periciales. La SCL reconoce 6 técnicas mientras que la AACE reconoce 8, muchas de ellas tienen distintos nombres, pero son muy parecidas o tienen nombres parecidos pese a ser completamente diferentes. Sin embargo, es habitual acabar empleando únicamente unas pocas de estas técnicas.

Collapse as built (CAB) + Impacted as planned (IAP)

Impacted as Planned se basa en la simulación de eventos de retraso sobre el programa de línea base, añadiendo actividades que representan los impactos ocurridos. Collapse as Built se basa en crear un modelo correctamente relacionado con las fechas as Built y todos los eventos de retraso que hayan tenido lugar. Ambas técnicas tienen fuertes debilidades que las hacen desaconsejables para un informe pericial, sin embargo, combinando ambas es posible realizar un análisis robusto y preciso.

La técnica CAB+IAP es una técnica muy poco usada por su complejidad y tiempo de implementación. Es únicamente adecuada para proyectos de poca envergadura, con cronogramas que no superen las 600 o 700 actividades y con numerosos retrasos concurrentes y caminos subcríticos. Este método implica la creación de un cronograma «As Built», donde todas las actividades reflejan la duración real y la lógica seguida en la práctica. Posteriormente, es necesario evaluar los eventos de retraso que han afectado el proyecto, así como los cambios de lógica y perdidas de rendimiento. Esta técnica avanzada busca ser capaz de analizar en detalle todo el cronograma pasando del cronograma As Built al cronograma As Planned mediante el colapsado de los retrasos y la restitución de la lógica original.

Pasos para implementar el método

Para emplear esta técnica en informes periciales de manera efectiva, es crucial implementar estrategias que aborden sus limitaciones. El primer paso es crear el modelo que representa el cronograma As Built. Esto puede lograrse añadiendo actividades específicas, ajustando la duración de las actividades y modificando las relaciones para que se ajuste a la realidad constructiva.

Una vez creado el modelo, el siguiente paso es colapsar los retrasos y analizar la diferencia entre el cronograma resultante y el cronograma As Planned. Para colapsar el modelo se tienen que eliminar (duración 0) las actividades de retraso creadas y restituir la duración original contractual de las actividades. Dado que la secuencia lógica de las actividades probablemente es distinta a la contractual, el cronograma colapsado no tendrá las mismas fechas que el planificado.

El tercer paso es identificar los cambios en la lógica que diferencian el cronograma As Built colapsado y el As Planned. Normalmente las actividades en el cronograma planificado se relacionan Fin Comienzo, sin embargo, en el as Built pasan a ser Fin-Fin más lag o Inicio-Inicio más lag. El análisis de la lógica es un proceso tan laborioso y complejo como la creación del modelo as Built colapsable. Para facilitar la transición del cronograma «As Built» al «As Planned», la preparación de hojas de cálculo con todos los cambios y con posibilidad de importación directa a Primavera P6, es imprescindible.

Posteriormente hay que analizar la responsabilidad de los cambios de secuencia y relaciones, perdidas de rendimiento y eventos de retraso. Una vez con los eventos y los cambios de lógica detectados es posible pasar del cronograma contractual al “As Built” de forma automática y calcular la responsabilidad del retraso de cada una de las partes. Para automatizar el paso del “As Built” a “As Planned” resulta muy práctico la preparación de un Excel de forma que con una simple importación a P6 se pueda pasar de uno a otro.

Al final de todo el proceso se obtiene un cronograma “As Built”, que, una vez colapsados los eventos y cambios tanto del contratista como del cliente, da lugar al cronograma contractual. Será posible colapsar únicamente los retrasos del cliente para calcular el retraso excusable compensable, y se podrá colapsar igualmente el retraso responsabilidad del contratista para calcular el retraso no excusable. El restante, se corresponde con el retraso excusable no compensable.

Esta técnica solo debe implementarse en proyectos sencillos, con pocos cambios de secuencia y en el que la parte interesada es la responsable principal de los retrasos críticos y la otra parte de retrasos subcríticos o concurrentes. El análisis permite detectar de forma muy precisa los retrasos concurrentes y determinar de forma justa las responsabilidades y compensaciones.

Debilidades del CAB+IAP
  • No considera los programas contemporáneos del proyecto.
  • Crear el modelo requiere de mucho trabajo, gran detalle en la información as Built y técnicos muy experimentados en el manejo de software y análisis de retrasos.
  • Crear la lógica para replicar las condiciones as Built requiere decisiones subjetivas que pueden no coincidir con las planificaciones contemporáneas.
  • Dificil de explicar a un tribunal.
  • Ignora el camino crítico de forma prospectiva en los programas contemporáneos y las decisiones críticas que se hayan podido tomar en base a ellos.
  • Se necesita una línea base en formato electrónico razonable y correctamente relacionada.


As Built vs As Plan Contemporaneous Windows Analysis

As-Planned vs As-Built Contemporaneous Windows Analysis es una de las técnicas más utilizadas en informes periciales por su simplicidad y por la posibilidad de no depender de un software de planificación y las actualizaciones.

Una vez recopilada toda la información necesaria se analiza revisando los programas contemporáneos, actas de obra y toda la información disponible que permita evaluar los eventos de retraso y el camino crítico. El proyecto se divide en ventanas definidas por cambios de criticidad o eventos relevantes.

El experto determina la ruta crítica real para cada una de las ventanas mediante la aplicación de su experiencia y la información disponible, siendo de especial relevancia el razonamiento seguido para definir el camino crítico, para ello se deben seguir los mismos pasos que en el método As-Planned vs As-Built.

El retraso de cada ventana es determinado mediante la comparación de hitos o fechas clave entre el cronograma contemporáneo y la línea base. Posteriormente se analiza que eventos son los causantes de dicho retraso al igual que su responsable.

La ventaja de realizar el análisis en varios periodos de tiempo es que la identificación de retrasos o aceleraciones puede ser mucho más precisa y fácil de entender. La definición de las ventanas debe estar basada en hitos relevantes o cambios de criticidad.

Es posible confundir esta técnica con la técnica Time Slice Analysis (TSA). Ambas consideran el camino crítico de forma dinámica dividiéndolo en secciones o ventanas. Sin embargo, TSA compara el retraso de cada ventana con la ventana anterior, por lo tanto, teniendo en cuenta las replanificaciones y dependiendo totalmente del software de planificación y las actualizaciones. De esta forma, es más susceptible a las modificaciones del cronograma con fines comerciales, mientras que ABAPW simplemente compara lo realizado con el plan acordado teniendo en cuenta el camino crítico de forma contemporánea ya que usa las actualizaciones y la opinión contemporánea de las partes.


Debilidades del ABAPW
  • No resulta apropiado para proyectos con actividades con poco margen de demora en las actividades (total float) o lo que es lo mismo con varios caminos subcríticos.
  • Depende de los conocimientos, experiencia y criterio del técnico que realiza el análisis.
  • Es complicado detectar y analizar retrasos concurrentes.
  • Análisis complejo cuando hay grandes cambios de secuencia.


Time Impact Analysis

Time Impact Analysis (TIA) es una técnica muy empleada para calcular y justificar reclamaciones de extensión de tiempo (EoT) debido a un evento en particular. Cuando se producen retrasos en el proyecto fuera de la responsabilidad del contratista, este debe solicitar una extensión de tiempo. El contratista debe proporcionar la documentación que acredite la existencia del retraso y que, de acuerdo con el contrato, está fuera de su alcance o responsabilidad. Además, es necesario calcular el impacto de este retraso.

La principal forma de calcular el efecto de un retraso concreto es mediante la técnica Time Impact Analysis, ya que permite cuantificar el efecto que tendrá un evento de forma prospectiva. Este método implica agregar actividades a un cronograma actualizado para representar el retraso. Una vez que se agrega al cronograma una o varias actividades correctamente relacionadas se podrá analizar el impacto que tendrá en la finalización del proyecto. Cuanta más información pueda dar el contratista sobre el efecto del retraso, más probabilidades habrá de que se apruebe una prórroga.

Pasos para implementar el método

La implementación del método de puede resumir en tres pasos:
Primero se debe identificar en qué actualización se va a insertar el evento o eventos a analizar. Por lo general, esta será la última actualización del cronograma aceptada antes de la fecha de impacto.

Posteriormente se añaden y relacionan las actividades que modelan el evento de retraso en el cronograma actualizado. A veces puede resultar complicado determinar dónde y cómo insertar las actividades para representar el evento lo más fielmente posible. Es importante analizar las relaciones de las actividades críticas puesto que si el evento no impacta el camino crítico no se podrá reclamar ninguna extensión de tiempo.

Por último, analizar los impactos en el cronograma modelado contra la última actualización aprobada para así determinar el impacto.