Descripción

Collaps as Built también conocida como “but for” es una técnica modelada basada en la simulación de escenarios. Esta simulación se realiza en un software de cálculo de ruta crítica como puede ser Ms Project o Primavera P6. Con este método se puede determinar la fecha más temprana en la que se podrían haber terminado los hitos en caso de que los retrasos de alguna de las partes no hubieran existido.

Se trata de un método de lógica estática ya que las relaciones del modelo no cambian en las distintas etapas de análisis. Los métodos con una lógica dinámica son considerados los más adecuados para un informe pericial. Este método se basa en la lógica as Built por lo que se puede emplear para realizar un análisis forense.

La dificultad de este método radica en crear un modelo correctamente relacionado con las fechas as Built y todos los eventos de retraso que hayan tenido lugar. No resulta aconsejable para proyectos muy largos con muchas actividades y sin una lógica constructiva muy clara y definida.

Para realizar el análisis de retrasos empleando esta metodología se deben seguir los siguientes pasos:

  • Localizar el programa as Built e identificar los retrasos, duraciones de actividades y fechas de inicio y fin.
  • Comenzar a crear el modelo en algún software CPM con las duraciones reales de las actividades y los eventos de retraso que hayan tenido lugar identificado el responsable de estos. Se puede usar un calendario de 7 días a la semana ya que así todos los cálculos serán directamente en días naturales. Además, es habitual realizar actividades fuera del periodo laboral planificado inicialmente. Se debe tener en cuenta que en algunos casos se producen resultados anómalos, por ejemplo, en el caso de una actividad que comenzó un viernes y finalizó el lunes siguiente, la duración asignada será de 4 días, aunque solo se trabajaron realmente en 2 aunque el sistema tiende a equilibrarse ya que habrá otras actividades que una vez colapsado queden programadas para un periodo que en el calendario de proyecto fuera considerado no laboral.
  • Una vez creado el modelo con los eventos de retraso se procede a cambiar la duración de los retrasos responsabilidad de alguna de las partes a 0 para así calcular la fecha más temprana de finalización en caso de que no hubieran acontecido los retrasos de alguna de las partes
  • Se debe realizar el mismo proceso para los retrasos de la otra parte

Fortalezas

  • Es un método robusto que si se realiza correctamente permite hacer análisis periciales buenos.

 

  • Tiene en cuenta todos los retrasos acontecidos en el proyecto por lo que permite evaluar el impacto de rutas subcríticas.

 

  • No es necesario una línea base en formato electrónico ni actualizaciones contemporáneas.

 

  • Es conceptualmente fácil de entender y presentar.

 

  • Permite analizar retrasos concurrentes e identificar los impactos de los retrasos de cada una de las partes una vez creado el modelo.

 

  • Pocos técnico de análisis de retrasos aplican este método.

 

  • Es una técnica que permite ser aplicada mientras el proyecto está en ejecución para calcular extensiones de tiempo o previsiones de penalizaciones.

Debilidades

  • 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.

 

  • Susceptible de intencionada o no intencionada manipulación en el proceso de modelado.

 

  • Ignora los caminos crítico prospectivos en los programas contemporáneos y las decisiones críticas que se hayan podido tomar en base a ellos.