La programación representa el plan. No lo sustituye.
En muchos proyectos el cronograma se convierte, por costumbre, en el lugar donde intentamos resolver decisiones que todavía no fueron tomadas. El resultado parece sofisticado: miles de actividades, relaciones lógicas, calendarios, constraints y una ruta crítica. Pero una red CPM no puede decidir cómo se va a ejecutar un proyecto.
Planning responde cómo se ejecutará: alcance, estrategia, métodos, recursos, responsabilidades, interfaces y secuencia. Scheduling traduce ese plan aprobado a actividades, duraciones, relaciones, calendarios e hitos para representar cuándo y en qué orden.
Qué ocurre cuando se programa antes de planificar
Cuando las decisiones no se cierran antes, el scheduler empieza a “resolver” el proyecto dentro del software. Allí aparecen cuatro síntomas clásicos:
- Programas paralelos. Ingeniería, ejecución, procurement o contratistas mantienen versiones distintas del mismo proyecto.
- La lógica sostiene el modelo, no la obra. Se agregan relaciones para conservar fechas o coherencia gráfica, no para representar la secuencia física.
- La estructura mezcla dos lógicas. Una WBS tradicional intenta convivir con AWP sin un mapping gobernado.
- El tiempo se consume reconciliando. Cada decisión pendiente reaparece como una nueva revisión aguas abajo.
El peor efecto no siempre es un cronograma “malo”. Es que el programa tarda demasiado en quedar listo porque se convirtió en el lugar donde se descubren decisiones, en vez del lugar donde se representan.
Planificar hacia atrás desde startup
Para proyectos de capital, el plan maestro debería construirse desde la condición final requerida: energización, system completion, commissioning, startup y capacidad operacional. Esa demanda se traduce hacia atrás en construcción, suministros, ingeniería, contratos y recursos.
La Schedule Basis es el contrato intelectual del cronograma
La AACE RP 38R-06 existe precisamente para documentar la base del schedule. Un cronograma confiable necesita explicitar qué está representando: scope, calendarios, logic, durations, assumptions, exclusions, constraints y criterios. Sin una base documentada, una fecha puede parecer precisa y seguir estando sustentada por premisas no acordadas.
La programación no puede representar lo que la planificación no ha decidido.