Microsoft Project y Primavera P6: herramientas, no magia

Un contratista entrega un cronograma elaborado en Primavera P6. Otro presenta su programa en Microsoft Project. Ambos muestran actividades, hitos y una fecha de término. Para el mandante, la pregunta importante es cuánto respaldo tiene esa fecha: ¿representa una secuencia ejecutable o solamente ordena las fechas que alguien esperaba cumplir?

Contar con un software de programación ayuda a organizar y analizar el proyecto. Sin embargo, una licencia no define el alcance, no verifica lo ocurrido en terreno y no resuelve las decisiones pendientes. La planificación y el control requieren método, información confiable y responsables que actúen sobre los resultados.

Project y Primavera P6 son herramientas valiosas. Su utilidad depende de cómo se construye, actualiza e interpreta el modelo del proyecto.

Qué aporta el software y qué debe aportar el equipo

Microsoft explica que el cálculo del cronograma en Project depende de factores como las relaciones entre tareas, las restricciones, los calendarios y las asignaciones de recursos. También distingue entre tareas programadas manual y automáticamente: el modo elegido cambia cómo responde la programación. Por eso, antes de confiar en una fecha conviene conocer las reglas que la producen. Esta explicación corresponde a las aplicaciones de escritorio indicadas en la documentación de Microsoft, no a cualquier producto que incluya la palabra Project.

En Primavera P6, las relaciones entre actividades y sus duraciones intervienen en la determinación de las fechas. Oracle describe esas dependencias en About Relationships. El programa puede procesar la lógica que recibe; la definición y validación de esa lógica siguen siendo trabajo del equipo.

Para una gerencia de proyectos, esta diferencia tiene una consecuencia práctica: solicitar el archivo nativo resulta útil, pero también hay que pedir las bases de planificación. ¿Quién estimó las duraciones? ¿Qué condiciones permiten abrir cada frente? ¿Qué supuestos deben confirmarse? Un programa sin estas respuestas puede transmitir más seguridad de la que merece.

Planificar antes de llenar la carta Gantt

Una planificación útil comienza con conversaciones concretas entre ingeniería, construcción, abastecimiento y quienes deben aprobar o recibir los trabajos. El objetivo es establecer qué debe entregarse y qué necesita ocurrir para hacerlo posible.

Como mínimo, proponemos resolver cinco asuntos antes de dar por terminado el programa:

• Alcance: entregables, límites e interfaces entre contratos o especialidades.
• Secuencia: condiciones reales que permiten comenzar y terminar cada actividad.
• Estimaciones: cantidades, rendimientos y supuestos que respaldan las duraciones.
• Disponibilidad: jornadas, accesos, personas, equipos y suministros considerados.
• Gobierno del plan: responsables de validar información, aprobar cambios y resolver restricciones.

Estos asuntos no se resuelven escogiendo colores o ajustando barras hasta que el término coincida con la fecha deseada. Exigen contrastar el programa con quienes ejecutarán el trabajo y dejar visibles las incertidumbres.

La guía de evaluación de cronogramas de la GAO trata el cronograma como una herramienta de gestión que permite evaluar si los parámetros del programa son realistas y qué efectos pueden tener los cambios. Ese propósito sirve como referencia: el archivo debe ayudar a decidir, no limitarse a acompañar un informe.

Ejemplo: un programa bien presentado con una condición faltante

Ejemplo hipotético y simplificado. No corresponde a un cliente ni a resultados de Plannit.

Supongamos una intervención con tres actividades consecutivas, todas con el mismo calendario y sin solapes:

1. Preparar el área: 4 jornadas laborables.
2. Instalar un equipo: 3 jornadas laborables.
3. Ejecutar pruebas: 2 jornadas laborables.

La cadena suma 4 + 3 + 2 = 9 jornadas laborables, contadas desde su inicio. El informe presenta ese resultado y el equipo interpreta que podrá completar la intervención en nueve jornadas.

Sin embargo, las pruebas requieren que el mandante libere una interfaz operativa. Esa condición no aparece en el programa. Para este ejemplo, la interfaz estará disponible recién al comienzo de la jornada 11. Aunque la instalación termine al cierre de la jornada 7, las pruebas ocuparían las jornadas 11 y 12. El término de esta intervención pasaría al cierre de la jornada 12.

El cálculo original respondía al modelo ingresado; faltaba representar una condición real. Tampoco basta con escribir una fecha nueva: hay que identificar al responsable de la liberación, verificar su respaldo y vincularla con el trabajo dependiente.

Las tres jornadas de diferencia corresponden únicamente a esta cadena simplificada. Su efecto sobre el término del proyecto completo debe evaluarse dentro del programa integrado. No constituyen, por sí mismas, una conclusión sobre responsabilidad contractual.

Controlar exige información de terreno y una fecha de corte

Después de aprobar el programa, empieza otra tarea: sostener una lectura consistente de lo ocurrido y de lo que falta.

Oracle indica que, en P6, la fecha de datos se relaciona con el avance registrado y debe actualizarse al incorporar progreso y reprogramar. La documentación de Using the data date ayuda a entender por qué el corte importa. Mezclar registros de distintos períodos puede dificultar la interpretación del estado del proyecto.

En la práctica, proponemos acordar quién entrega los datos, qué evidencia los respalda y cómo se revisan antes de actualizar. El análisis debería distinguir:

• Lo efectivamente ejecutado y sus fechas reales.
• Lo pendiente, con estimaciones revisadas y condiciones por resolver.
• La diferencia respecto del compromiso de referencia.
• Las acciones necesarias, con responsable y fecha de decisión.

Para profundizar en el procedimiento, revisa cómo actualizar el cronograma de obra. La línea base merece un tratamiento separado: conservar la referencia permite discutir desviaciones sin reemplazar silenciosamente el compromiso por la última proyección.

Qué exigir antes de aceptar el próximo reporte

Este checklist sirve para revisar la utilidad de un programa, independientemente de la herramienta utilizada:

• ¿El informe identifica versión, fecha de corte y responsable?
• ¿Los hitos relevantes están conectados con el trabajo que permite cumplirlos?
• ¿Se explican las dependencias externas y sus responsables?
• ¿Las estimaciones tienen un respaldo reconocible y supuestos visibles?
• ¿El avance informado corresponde a evidencia revisable?
• ¿Se distingue la referencia aprobada de la proyección vigente?
• ¿Las desviaciones vienen acompañadas de alternativas y decisiones pendientes?
• ¿El equipo entiende qué condiciones podrían cambiar la fecha presentada?

Una respuesta incompleta no significa automáticamente rechazar todo el programa. Permite identificar qué debe aclararse antes de usarlo para comprometer una decisión.

Elegir la herramienta sin perder de vista el servicio

Project o Primavera P6 pueden formar parte del proceso. La elección debe considerar los requisitos del proyecto, las capacidades del equipo, el intercambio de información y la forma en que el mandante revisará los entregables. Cambiar de software sin corregir el proceso de control puede trasladar las mismas debilidades a otro archivo.

En Plannit, el servicio de planificación y control integrado de proyectos contempla diagnóstico del programa y del proceso de control, programa maestro o línea base, actualizaciones y pronóstico de término, e informes de avance y decisiones pendientes. El alcance se define según la información disponible y la necesidad del proyecto.

Si tu equipo ya utiliza Project o Primavera P6, podemos conversar sobre qué información necesita para decidir mejor y qué entregables conviene revisar. Conoce nuestros servicios en www.plannit.cl o escribe a Contacto@plannit.cl.

Las fuentes se consultaron el 22 de octubre de 2026, hora de Chile. Las referencias a productos describen la documentación enlazada; no implican certificación ni representación comercial de sus fabricantes.