En Primavera P6, la fecha de corte o Data Date representa el límite temporal hasta el cual se ha actualizado el avance real del proyecto. Todo lo ocurrido antes de esa fecha puede formar parte del registro real del cronograma; todo lo que ocurre desde esa fecha en adelante pertenece al futuro planificado.

Por esta razón, una actividad no debería tener fechas reales de inicio o término iguales o posteriores al Data Date. Si esto ocurre, el cronograma está mostrando eventos reales en un periodo que todavía no debería contener avance registrado.

El análisis de xerPlanner identifica actividades que tienen una fecha real de inicio o una fecha real de término igual o posterior a la fecha de corte, considerando el alcance seleccionado para el reporte. Esta condición representa una inconsistencia clara en el proceso de actualización del cronograma y debe revisarse cuidadosamente.

El Data Date marca el punto exacto hasta el cual se conoce el estado real del proyecto. Si una actividad tiene una fecha real igual o posterior a ese punto, el cronograma está informando como real algo que, según su propia fecha de corte, todavía pertenece al futuro o al límite exacto desde el cual no deberían registrarse nuevos eventos reales.

La siguiente captura muestra un ejemplo de una actividad con fechas reales inconsistentes respecto de la fecha de corte del proyecto. Este tipo de situación puede parecer un error menor de carga, pero afecta directamente la confiabilidad del cronograma actualizado.

Esta inconsistencia puede generar varios problemas:

  • distorsión del estado real del proyecto;
  • pérdida de confianza en el proceso de actualización;
  • diferencias entre el avance reportado y el periodo realmente controlado;
  • errores en la interpretación de actividades iniciadas o terminadas;
  • problemas en revisiones de calidad, auditorías o análisis forenses del cronograma;
  • debilidad técnica frente a eventuales reclamaciones o análisis de impacto.

La pregunta de fondo es simple: si el Data Date indica hasta dónde se conoce el avance real, ¿cómo puede existir una fecha real igual o posterior a ese punto? En ese caso, o la fecha real fue ingresada incorrectamente, o el Data Date no representa correctamente la fecha de control utilizada para la actualización.

xerPlanner reporta actividades que cumplen alguna de estas condiciones:

  • tienen una fecha real de inicio igual o posterior al Data Date; o
  • tienen una fecha real de término igual o posterior al Data Date.

El análisis compara las fechas reales de la actividad contra la fecha de corte del proyecto. En la base de datos de Primavera P6, esta fecha corresponde al campo asociado a la última fecha de recálculo del proyecto, utilizado por xerPlanner como referencia del Data Date.

El informe muestra la actividad afectada, su duración remanente, sus horas labor remanentes, su fecha real de inicio, su fecha real de término y el Data Date del proyecto. Con esta información, el planificador puede identificar rápidamente si el problema está en la fecha real registrada, en el estado de la actividad o en la fecha de corte utilizada para actualizar el cronograma.

Este análisis puede entregar resultados distintos según el alcance definido para el reporte. Si el usuario selecciona un análisis enfocado solo en actividades remanentes, es posible que aparezcan pocos hallazgos, porque muchas inconsistencias asociadas a fechas reales se encuentran en actividades que ya fueron iniciadas o terminadas durante el proceso de actualización.

En ese caso, xerPlanner puede detectar actividades en progreso con una fecha real de inicio igual o posterior al Data Date, pero pueden quedar fuera actividades ya completadas con fechas reales de término inconsistentes respecto de la fecha de corte.

Por esta razón, si el objetivo es revisar la calidad de la actualización del cronograma, conviene aplicar este análisis sobre un alcance que incluya también actividades completadas. De lo contrario, el reporte puede subestimar la cantidad real de inconsistencias asociadas a fechas reales fuera del periodo de control.

Esta consideración es especialmente importante porque este tipo de hallazgo suele originarse precisamente durante el proceso de actualización. Es decir, no siempre se encuentra en el trabajo pendiente, sino en la información real registrada para representar el avance del periodo.

Este hallazgo es especialmente sensible porque es fácil de detectar y difícil de justificar. En una auditoría o en un análisis forense de cronograma, las fechas reales iguales o posteriores al Data Date pueden interpretarse como una señal de debilidad en el proceso de actualización.

En contextos de reclamaciones, extensión de plazo o análisis de impacto, la confiabilidad de las fechas reales es fundamental. Si el cronograma contiene fechas reales que no son consistentes con su propia fecha de corte, se debilita la trazabilidad del avance y puede cuestionarse la calidad de la información utilizada para sustentar conclusiones contractuales.

Por eso, este tipo de hallazgo no debería tratarse como un detalle menor. Aunque corregirlo suele ser sencillo, mantenerlo de forma recurrente puede afectar seriamente la credibilidad del cronograma y del proceso de control del proyecto.

La mejor práctica es definir claramente una fecha de control para cada periodo de actualización y registrar únicamente el avance real ocurrido antes de esa fecha. El Data Date debe representar de manera consistente el límite del periodo informado.

Antes de cerrar una actualización, se recomienda revisar que ninguna actividad tenga fechas reales iguales o posteriores al Data Date. Si se detecta una inconsistencia, se debe corregir la fecha real, ajustar el Data Date si corresponde, o revisar el procedimiento utilizado para actualizar el cronograma.

También es recomendable ejecutar este análisis con un alcance suficientemente amplio cuando el objetivo sea validar la calidad de la actualización. Revisar solo el trabajo remanente puede ser útil para ciertos controles, pero no siempre es suficiente para detectar errores en fechas reales de actividades ya completadas.

Un proceso disciplinado de actualización debería incluir la recopilación de avance, validación de fechas reales, actualización de actividades, recálculo del cronograma y revisión de inconsistencias antes de emitir reportes. Este control simple puede prevenir errores que luego tienen un impacto importante en auditorías, análisis de desempeño o reclamaciones.

Las actividades con fechas reales iguales o posteriores a la fecha de corte representan una inconsistencia directa en la actualización del cronograma. El Data Date define hasta dónde se conoce el avance real; por lo tanto, no deberían existir eventos reales registrados desde ese punto en adelante.

Este análisis debe interpretarse considerando el alcance seleccionado para el reporte. Si se revisan solo actividades remanentes, pueden quedar fuera actividades completadas con fechas reales inconsistentes. Por eso, cuando el objetivo sea evaluar la calidad de la actualización, es recomendable incluir también la parte actualizada del cronograma.

Corregir este hallazgo ayuda a mantener la coherencia temporal del cronograma, mejora la credibilidad del proceso de actualización y reduce riesgos en auditorías, análisis forenses y eventuales reclamaciones. Es una revisión simple, pero esencial para asegurar que el cronograma refleje fielmente el estado real del proyecto.