Actividades con restricciones absolutas

Introducción

Sin embargo, existen casos en los que una actividad tiene impuesta una fecha específica de inicio o término. En xerPlanner, estas se clasifican como restricciones absolutas, porque fijan una fecha única sobre la actividad y pueden alterar la lectura natural de la lógica, la holgura y la criticidad del cronograma.

Este análisis identifica actividades con restricciones primarias absolutas, específicamente:

• Mandatory Start
• Mandatory Finish
• Start On
• Finish On

Aunque estas restricciones no se comportan exactamente igual entre sí, todas tienen en común que incorporan una fecha puntual e inflexible. Por esa razón, xerPlanner las analiza separadamente de las restricciones de ventana, que permiten cierto margen temporal hacia un lado de la fecha definida.

En Primavera P6 no existen restricciones secundarias de tipo absoluto; las restricciones secundarias corresponden a restricciones de ventana. Por ello, este análisis se enfoca únicamente en restricciones primarias absolutas.

El impacto de las restricciones absolutas

Las restricciones absolutas pueden afectar la calidad del cronograma porque introducen una fecha impuesta por sobre la lógica natural de la red. Esto puede hacer que una actividad se ubique en una fecha determinada no necesariamente porque la secuencia lógica la llevó hasta ahí, sino porque existe una restricción que condiciona su inicio o término.

Las restricciones Mandatory Start y Mandatory Finish son las más rígidas, ya que imponen directamente una fecha obligatoria de inicio o término. Estas restricciones pueden dominar la lógica de la actividad y afectar la forma en que se calculan sus fechas y holguras.

Por otro lado, restricciones como Start On y Finish On pueden permitir que la lógica tenga cierto efecto cuando existe conflicto, pero aun así fijan una fecha específica que impacta la holgura, la criticidad o la cadena de actividades predecesoras. Por esta razón, xerPlanner también las considera restricciones absolutas desde un punto de vista analítico.

El problema principal no es que una restricción absoluta sea siempre incorrecta. Puede existir una justificación contractual, técnica, operacional o estratégica para imponer una fecha específica. El riesgo aparece cuando estas restricciones se utilizan para forzar el cronograma en lugar de corregir la lógica que debería explicar naturalmente esa fecha.

En la siguiente imagen se observa una actividad con una restricción Mandatory Finish, donde el término de la actividad queda asociado a una fecha específica. Este tipo de configuración puede ser válido si responde a una condición real del proyecto, pero debe revisarse porque puede influir directamente en la holgura, criticidad y lectura lógica del cronograma.

Diferencia con las restricciones de ventana

Las restricciones absolutas fijan una fecha única. En cambio, las restricciones de ventana establecen un límite temporal, permitiendo que la lógica del cronograma se mueva con mayor libertad hacia un lado de esa fecha.

Por ejemplo, una restricción tipo Start On or After establece que la actividad no puede comenzar antes de cierta fecha, pero sí puede comenzar después si la lógica del cronograma así lo determina. De forma similar, una restricción tipo Finish On or Before establece un límite máximo de término, pero permite que la actividad termine antes si la lógica lo permite.

Esa diferencia es relevante para el análisis de calidad del cronograma. Las restricciones absolutas tienden a imponer una fecha específica, mientras que las restricciones de ventana actúan como límites. Ningún tipo de restricción debe usarse sin justificación, pero las restricciones absolutas suelen requerir una revisión más estricta porque reducen con mayor fuerza la capacidad de la red lógica para calcular fechas de manera natural.

Casos que deben interpretarse con cuidado

Una restricción absoluta no debe interpretarse automáticamente como un error. En algunos proyectos puede ser necesario fijar una fecha por razones contractuales, compromisos con terceros, ventanas operacionales, hitos regulatorios, accesos restringidos, entregas críticas o condiciones externas al cronograma.

Sin embargo, estas restricciones deben estar justificadas. Si se usan solo para hacer que el cronograma “calce” con una fecha deseada, pueden ocultar problemas de lógica, generar holguras artificiales o distorsionar la ruta crítica.

También es importante distinguir entre una fecha objetivo y una restricción absoluta. Si una actividad debe monitorearse respecto de una fecha comprometida, puede ser más adecuado utilizar hitos, líneas base, campos personalizados, códigos o reportes, en lugar de imponer una restricción que modifique el comportamiento del cálculo.

En términos de calidad del cronograma, una restricción absoluta debería responder a una condición real del proyecto y no a una corrección manual de fechas.

Mejores prácticas para gestionar restricciones absolutas

Para gestionar correctamente este tipo de hallazgo, lo primero es revisar por qué fue aplicada la restricción y si existe una justificación válida para mantenerla.

En términos prácticos, la revisión debería considerar al menos lo siguiente:

• Confirmar si la restricción responde a una obligación contractual, técnica, operacional o externa al cronograma.
• Verificar si la fecha impuesta podría obtenerse mediante una lógica de vínculos correctamente construida.
• Revisar si la restricción está afectando la holgura total, la criticidad o la ruta crítica del proyecto.
• Evaluar si la restricción está ocultando una deficiencia de secuencia lógica.
• Documentar explícitamente la justificación cuando la restricción deba mantenerse.
• Reemplazar la restricción por lógica de vínculos cuando la fecha pueda explicarse mediante dependencias reales.
• Usar hitos, líneas base u otros mecanismos de control cuando solo se requiera monitorear una fecha objetivo.

Al aplicar estas revisiones, el cronograma mantiene una lógica más confiable y reduce el riesgo de que sus fechas dependan de imposiciones manuales no justificadas.

Conclusión

Las restricciones absolutas pueden tener un impacto significativo en la calidad de un cronograma porque fijan fechas específicas de inicio o término que pueden alterar la holgura, la criticidad y la lectura natural de la red lógica.

En xerPlanner, este análisis identifica actividades con restricciones primarias absolutas: Mandatory Start, Mandatory Finish, Start On y Finish On. Estas restricciones se diferencian de las restricciones de ventana porque no establecen solo un límite flexible, sino una fecha puntual que debe ser revisada con especial cuidado.

Revisar estas restricciones permite distinguir entre condiciones realmente justificadas y ajustes manuales que podrían estar debilitando la lógica del cronograma. Cuando una restricción absoluta no está debidamente fundamentada, lo recomendable es corregir la secuencia lógica del cronograma en lugar de forzar sus fechas.