As-planned versus as-built: qué prueba y qué no

Comparar el programa aprobado con lo que realmente se construyó es la primera cosa que hace cualquiera que investiga un atraso. Es intuitivo, es barato y no necesita software especializado. También es el método que más se sobreinterpreta.

Qué es y dónde se ubica

En la clasificación de la práctica recomendada 29R-03 de AACE International, este método es el protocolo MIP 3.1, cuyo nombre taxonómico es observacional, estático y bruto. Observacional porque el analista no altera el cronograma para simular escenarios que no ocurrieron, a diferencia de los métodos modelados. Estático porque no sigue cómo fue evolucionando la lógica. Y bruto porque mira el proyecto completo de una vez, sin dividirlo en períodos.

Andrew Avalon, en un artículo de 2016 publicado por Long International que reproduce con permiso el texto del RP, resume la mecánica: compara el programa as-planned con el as-built, y en su aplicación más simple no usa lógica CPM explícita. Es un estudio observacional de fechas de inicio y término.

Ahí está su atractivo y su límite. Muestra qué partidas empezaron o terminaron después de lo previsto, pero no explica por qué el término del proyecto se movió.

Lo que el método no puede hacer

La propia 29R-03 lo dice entre sus premisas básicas: los cronogramas, por sí solos, no demuestran la causa raíz ni la responsabilidad de los atrasos. Y agrega otra advertencia que conviene citar cuando alguien presenta un informe como si fuera aritmética: ningún método de análisis forense es exacto, porque su exactitud depende de la calidad de los datos y de juicios subjetivos del analista.

La práctica tampoco pretende fijar un estándar de práctica profesional, así que apartarse de un protocolo no es automáticamente un error, siempre que la decisión esté fundada.

Avalon enumera además las situaciones donde el MIP 3.1 se considera en general inadecuado:

• Proyectos con decenas de actualizaciones del programa.
• Obras construidas de forma muy distinta a lo planificado.
• Proyectos con múltiples rutas críticas.
• Proyectos donde la ruta crítica cambió varias veces.
• Situaciones con atrasos concurrentes o con pacing, es decir, cuando una parte desacelera porque otra ya está atrasada. Ese terreno lo tratamos en atrasos concurrentes.

No confundir la versión simple con la versión por ventanas

Aquí se produce el malentendido más frecuente. El Protocolo de la Society of Construction Law nombra un método llamado as-planned versus as-built windows analysis, que es por ventanas. Patrick Weaver, en su revisión de 2023 del Protocolo, lo relaciona con el MIP 3.2 de AACE y no con el 3.1. La versión no segmentada aparece en el Protocolo como una opción secundaria, para un análisis retrospectivo de todo el proyecto.

La distinción importa porque el RP advierte que segmentar en períodos no aumenta por sí solo la exactitud técnica del análisis: puede dar apariencia de mayor detalle sin que lo haya. Cómo funciona realmente la versión por ventanas lo explicamos en análisis por ventanas, y la clasificación completa en los métodos de la 29R-03.

Conviene además tratar las equivalencias entre el Protocolo SCL y AACE como lecturas de autor y no como hechos cerrados: el propio Weaver asigna el MIP 3.1 a otro de los métodos del Protocolo, lo que muestra que el mapeo admite más de una interpretación.

Cuándo sí conviene usarlo

El Protocolo SCL entrega dos criterios prácticos. El primero es de insumos: este método necesita solo el programa base y los datos de lo construido, mientras que los métodos modelados exigen un programa con lógica y una selección de eventos. El segundo es de contexto: su variante por ventanas se aplica normalmente cuando hay dudas sobre la validez o la razonabilidad del programa base, o cuando existen muy pocas actualizaciones contemporáneas, y depende poco del software.

Dicho de otro modo: cuando los registros de programación son pobres, este método puede ser lo único disponible. En esos casos su resultado sirve para describir qué pasó, no para atribuir responsabilidad.

La elección ya no tiene un ganador por defecto

La segunda edición del Protocolo SCL, de 2017, eliminó la preferencia por un método único cuando el análisis se hace mucho tiempo después del evento. En su lugar propone criterios de elección: lo que exige el contrato, la naturaleza del evento y del proyecto, la proporcionalidad, el tiempo disponible, la calidad de los registros, la calidad de la información de programación y el foro en que se resolverá.

Ese cambio deja al as-planned versus as-built en su sitio correcto. Es un buen punto de partida, un buen apoyo visual y una mala prueba aislada. Para sostener causalidad hay que agregar los registros del proyecto y, cuando los datos lo permiten, un método que siga la evolución de la ruta crítica. Lo primero lo tratamos en por qué los reclamos se ganan en los registros.