Vínculos entre actividades con desfases positivos (o lags) de duración excesiva

Introducción

Sin embargo, cuando un lag positivo es demasiado largo en comparación con la duración de la actividad predecesora, puede indicar que el cronograma está ocultando trabajo o condiciones que deberían estar representadas explícitamente como actividades. Esto debilita la trazabilidad de la red lógica y reduce la transparencia del plan.

El análisis de xerPlanner identifica relaciones entre actividades con lags positivos cuya duración se considera excesiva. El objetivo es advertir casos donde el desfase podría estar reemplazando actividades intermedias, esperas controlables o decisiones de programación que deberían revisarse con mayor detalle.

Cuándo se considera excesivo un lag

En este análisis, xerPlanner considera excesivo un lag positivo cuando supera el 10% de la duración de la actividad predecesora.

Por ejemplo, si una actividad predecesora dura 20 días, un lag de 1 día probablemente no sea relevante desde el punto de vista estructural. En cambio, si la predecesora dura 3 días, ese mismo lag de 1 día representa una proporción mucho más significativa de la secuencia lógica y merece revisión.

En el caso de los hitos, como no tienen duración propia, xerPlanner utiliza un criterio diferente: el lag se considera excesivo cuando supera un umbral equivalente al 10% de la duración total del proyecto, medida en días corridos desde su inicio hasta su término. Esta regla permite aplicar un criterio objetivo también a relaciones donde la actividad predecesora no tiene duración.

Este enfoque relativo puede parecer exigente cuando se observan valores absolutos pequeños, pero su objetivo es detectar desfases desproporcionados respecto de la lógica que están afectando. Un lag no debe evaluarse solo por su cantidad de días, sino también por su tamaño relativo dentro de la secuencia que modifica.

Por qué los lags excesivos pueden ser un problema

Un lag excesivo puede ocultar partes importantes del flujo de trabajo. Si el periodo representado por el lag requiere gestión, recursos, responsables, inspecciones, seguimiento o validación, probablemente debería estar modelado como una actividad independiente.

La siguiente captura muestra un ejemplo de relaciones con lags positivos en Primavera P6. Aunque estos desfases pueden parecer simples ajustes de secuencia, cuando su duración es alta en relación con la actividad predecesora pueden afectar la calidad lógica del cronograma.

Este tipo de condición puede generar varios problemas:

• ocultar actividades intermedias que deberían estar planificadas;
• dificultar el seguimiento del avance real;
• reducir la trazabilidad entre actividades relacionadas;
• impedir la asignación clara de recursos o responsables;
• distorsionar la interpretación de la ruta crítica;
• debilitar la transparencia del cronograma frente a revisiones, auditorías o análisis de planificación.

El problema no está en el uso de lags por sí mismo, sino en el uso de lags extensos como sustituto de una lógica más clara y controlable.

Casos que deben interpretarse con cuidado

No todo lag excesivo representa automáticamente un error. Puede haber casos donde el desfase responde a una espera técnica legítima o a una condición externa real. Por ejemplo, ciertos procesos de curado, aprobaciones regulatorias, restricciones de acceso o ventanas operacionales podrían justificar un intervalo importante entre dos actividades.

Aun así, mientras más largo sea el lag, más importante es revisar si conviene mantenerlo como desfase o transformarlo en una actividad explícita. Si el periodo tiene responsable, duración controlable, riesgo, recursos o posibilidad de avance, normalmente será mejor representarlo dentro del cronograma como una actividad propia.

También es importante considerar que el umbral relativo puede detectar casos que parecen pequeños en días absolutos. Esto es intencional. Un lag corto puede ser relevante si afecta una actividad de duración muy baja, porque altera de manera importante la proporción lógica entre predecesora y sucesora.

Relaciones externas marcadas con [e]

xerPlanner puede marcar con [e] los hallazgos asociados a relaciones externas, es decir, vínculos entre actividades que pertenecen a proyectos distintos dentro del archivo XER.

Esta marca indica que el hallazgo depende de la existencia de esa relación externa. Si el archivo XER se importa en una base de datos donde el proyecto externo relacionado no existe, la relación puede desaparecer y, por lo tanto, también puede desaparecer el lag que generaba el hallazgo. En cambio, si el cronograma se revisa o importa en una base donde el proyecto externo sí existe, la relación se mantiene y el hallazgo sigue siendo válido.

Por eso, la marca [e] no debe interpretarse como una corrección automática ni como un hallazgo menor. Es una advertencia sobre la dependencia del hallazgo respecto de una relación externa.

Mejores prácticas

La mejor práctica es revisar cada lag positivo excesivo y confirmar qué representa realmente. Si corresponde a una espera técnica simple, justificada y sin necesidad de control detallado, puede mantenerse como lag.

Si el desfase representa trabajo, gestión, inspección, aprobación, traslado, liberación de área, espera relevante o cualquier condición que deba controlarse, lo recomendable es reemplazarlo por una actividad explícita. Esto mejora la trazabilidad, permite asignar responsables, facilita el seguimiento y hace que la lógica del cronograma sea más transparente.

También es recomendable evitar el uso de lags extensos para ajustar fechas de forma artificial. Un cronograma de buena calidad debe explicar la secuencia de ejecución mediante actividades y relaciones lógicas comprensibles, no mediante intervalos ocultos que dificulten la revisión del plan.

Conclusión

Los lags positivos de duración excesiva no son necesariamente incorrectos, pero sí son una señal clara de revisión. Un desfase puede estar justificado, pero cuando es demasiado grande en relación con la duración de la actividad predecesora, puede indicar que el cronograma está ocultando trabajo, esperas relevantes o decisiones de programación que deberían representarse de forma explícita.

Revisar estos hallazgos permite validar si los lags reflejan fielmente la secuencia real del proyecto o si deben reemplazarse por actividades más claras y controlables. Un cronograma transparente no solo muestra cuándo ocurren las actividades, sino también qué sucede entre ellas.